Model Builder Error

Model Builder Version: 16.0.2003.302
Visual Studion Version: 2019
Error:
Tensorflow exception triggered while loading model.
в Microsoft.ML.ModelBuilder.AutoMLService.Experiments.AutoMLExperiment`3.d__23.MoveNext() в E:\A_work\1326\s\Microsoft.ML.ModelBuilder.AutoMLService\Experiments\AutoMLExperiment.cs:строка 108
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
в Microsoft.ML.ModelBuilder.AutoMLEngine.d__28.MoveNext() в E:\A_work\1326\s\Microsoft.ML.ModelBuilder.AutoMLService\AutoMLEngineService\AutoMLEngine.cs:строка 134

Hello,
Thanks for reporting! Sorry you're hitting this issue. Can you share more details?
What are the specifications of your machine? How much memory/ram do you have?
Cheers,
Jake

SSD 500 Gb, 16 Gb RAM

Could you try uninstalling and re-installing the ModelBuilder extension. I've only seen this happen when an ML.NET dependency is missing. That shouldn't be possible since we package it with the Model Builder extension but perhaps it had issues installing.

If you can update to VS 2019 16.6 Preview 3 or newer -
https://devblogs.microsoft.com/visualstudio/new-in-visual-studio-2019-v16-6-preview-3/
We have a newer version of Model Builder available.

I tried in
в
Microsoft.ML.ModelBuilder.AutoMLService.Experiments.AutoMLExperiment`3.d__21.MoveNext()
в
//src/Microsoft.ML.ModelBuilder.AutoMLService/Experiments/AutoMLExperiment.cs:строка
106
--- Конец трассировка стека из предыдущего расположения, где возникло
исключение ---
в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
в
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)
в
Microsoft.ML.ModelBuilder.AutoMLEngine.d__30.MoveNext()
в
//src/Microsoft.ML.ModelBuilder.AutoMLService/AutoMLEngineService/AutoMLEngine.cs:строка
147
вт, 5 мая 2020 г. в 20:32, Jake<EMAIL_ADDRESS>
If you can update to VS 2019 16.6 Preview 3 or newer -
https://devblogs.microsoft.com/visualstudio/new-in-visual-studio-2019-v16-6-preview-3/
We have a newer version of Model Builder available.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/machinelearning-modelbuilder/issues/726#issuecomment-624199258,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANOA5DGUJTUDEBQEOUGKTW3RQBES3ANCNFSM4MXWR7DQ
.

Might be related to this issue:
https://github.com/dotnet/machinelearning/issues/5052

I find decision. Visual Studio Installer -> VS community 2019 -> additionally(Дополнительно) -> recover(Восстановить).

Microsoft Visual Studio Community 2019
Version 16.6.0
Adding ML.Net Builder to a Blazor Server Project .
Model Builder Error
Value cannot be null.
Parameter name: source
at System.Linq.Enumerable.Select[TSource,TResult](IEnumerable1 source, Func2 selector)
at Microsoft.ML.ModelBuilder.AutoMLService.Experiments.AutoMLExperiment`3.d__23.MoveNext() in E:\A_work\1326\s\Microsoft.ML.ModelBuilder.AutoMLService\Experiments\AutoMLExperiment.cs:line 117
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ML.ModelBuilder.AutoMLEngine.d__28.MoveNext() in E:\A_work\1326\s\Microsoft.ML.ModelBuilder.AutoMLService\AutoMLEngineService\AutoMLEngine.cs:line 134

@Darkne77 did you find a solution?
@lbdalmendray how large is your dataset?

Two images for each label folder ( label A => 2 images , label B => 2 images ). Total was 4 images. Sorry , I did not find a solution.  The images are jpg files .

I believe this can happen when the datset is too small. Can you try 10-20 images for each?

@JakeRadMSFT Thanks a lot ! I did it . I used 20 images for each label folder and It works. Solved !

Resolving issue! Please re-open if you run into any other issues.
Cheers,
Jake


Fix missing button

Re-added the play button in the top right in the experiments table webview. I removed it while cleaning the actions (without realizing I was editing the editor title actio

ns... my bad).

Thought this would fix e2e tests, but problem seems to be something else. This still need to be fixed though.


Linux/Unix support, continued from PR #37

After two months of inactivity on https://github.com/pond3r/ggpo/pull/37 I took the liberty to apply most of the requested changes.
The big open question is the implementation of the Poll functionality. Currently, the code still uses the POSIX implementation of the Win32 API. As a first version (and since the code is not being used in the vectorwar example) I think it's better to have this than nothing (or nothing that compiles).
For the case that you want to implement a more POSIX-style API before merging this, I looked into how to implement such an API. I think using file descriptors for signaling of events could be the most appropriate way to handle these (if I understood this API correctly). Then we could use either select(3P) (available on both MacOSX and Linux) or epoll (Linux) and kqueue (MacOSX, though I have read online that this function can be buggy) to check which event has fired (i. e. which file descriptor is readable).
What do you think?

I think it's good.


CircuitError: "invalid param type <class 'numpy.ndarray'> for instruction  state_preparation"

What is the expected enhancement?
I tried executing the following very basic example for VQLS:
import numpy as np
from qiskit.primitives import Estimator, Sampler
from qiskit_algorithms.optimizers import COBYLA
from qiskit.circuit.library.n_local.real_amplitudes import RealAmplitudes
from vqls_prototype import VQLS, VQLSLog

if __name__ == "__main__":
    N = 1
    matrix_a = np.random.rand(2**N, 2**N)
    matrix_a += matrix_a.T
    vector_b = np.random.rand(2**N, 1)

    ansatz = RealAmplitudes(num_qubits=int(np.log2(matrix_a.shape[0])), entanglement="full", reps=3,
                            insert_barriers=False)

    # if vector_b.ndim == 2:
    #     vector_b = vector_b.flatten()

    log = VQLSLog([], [])
    estimator = Estimator()
    sampler = Sampler()
    vqls = VQLS(
        estimator,
        ansatz,
        COBYLA(maxiter=250, disp=True),
        sampler=sampler,
        callback=log.update,
    )
    opt = {"use_overlap_test": False, "use_local_cost_function": False}
    res = vqls.solve(matrix_a, vector_b, opt)

This results in the following traceback:
Traceback (most recent call last):
  File "/home/davidm/Projects/qc-quantum-linear-systems/quantum_linear_systems/minimal_test.py", line 35, in <module>
    res = vqls.solve(matrix_a, vector_b, opt)
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/vqls_prototype/vqls.py", line 807, in solve
    hdmr_tests_norm, hdmr_tests_overlap = self.construct_circuit(
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/vqls_prototype/vqls.py", line 323, in construct_circuit
    self.vector_circuit.prepare_state(vector / vec_norm)
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/qiskit/circuit/library/data_preparation/state_preparation.py", line 521, in prepare_state
    StatePreparation(state, num_qubits, label=label, normalize=normalize), qubits
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/qiskit/circuit/library/data_preparation/state_preparation.py", line 112, in __init__
    super().__init__(self._name, num_qubits, params, label=self._label)
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/qiskit/circuit/gate.py", line 37, in __init__
    super().__init__(name, num_qubits, 0, params, label=label)
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/qiskit/circuit/instruction.py", line 105, in __init__
    self.params = params  # must be at last (other properties may be required for validation)
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/qiskit/circuit/instruction.py", line 223, in params
    self._params.append(self.validate_parameter(single_param))
  File "/home/davidm/Projects/venvs/qls3.10/lib/python3.10/site-packages/qiskit/circuit/library/data_preparation/state_preparation.py", line 250, in validate_parameter
    raise CircuitError(f"invalid param type {type(parameter)} for instruction  {self.name}")
qiskit.circuit.exceptions.CircuitError: "invalid param type <class 'numpy.ndarray'> for instruction  state_preparation"

Which looks very confusing.
However, this is only due to the rank of the numpy array vector_b. (aka vector_b being passed as an ndarray of shape (m,1) instead of shape (m,)).
Consequently just by flattening the input vector (see the commented out lines in the example above), the code runs just fine.
Therefore, I'd like to suggest just integrating a test like that, for example around line 314 in vqls.py  in the function construct_circuit
        elif isinstance(vector, np.ndarray):
            # ensure the vector is double
            vector = vector.astype("float64")

adding a check that the vector is of the correct rank by checking if vector.ndim == 2:  vector = vector.flatten()

Thanks ! It took me a while but this is now fixed. Thanks for the input
It will be merged as part of #9 so i will close this issue


Reproducible Builds

Your app was requested for inclusion with the IzzyOnDroid repo.
At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more at IzzyOnDroid). Trying for yours, I was able to successfully generate the APK using ./gradlew assembleRelease, but the resulting APKs were not identical. The APK was obviously not built from a clean tree: the embedded commit hash suggests a commit before the tag, but the APK has versionName and versionCode with values committed with the tag. So obviously there were some local changes made after the first commit, then the APK was built, and then there might have been additional changes before the next commit:
  -rw-r--r--  0.0 unx       56 b-       52 defN 1981-01-01 01:01:02 32137644 META-INF/com/android/build/gradle/app-metadata.properties
- -rw-r--r--  0.0 unx      120 b-      117 defN 1981-01-01 01:01:02 dab95447 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     2660 b-     2660 stor 1981-01-01 01:01:02 a5a64965 assets/dexopt/baseline.prof
- -rw-r--r--  0.0 unx      189 b-      189 stor 1981-01-01 01:01:02 c16b9473 assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  9284468 b-  3467412 defN 1981-01-01 01:01:02 5dd0c4e1 classes.dex
+ -rw-r--r--  0.0 unx      120 b-      117 defN 1981-01-01 01:01:02 290f383c META-INF/version-control-info.textproto
+ -rw-r--r--  0.0 unx     2666 b-     2666 stor 1981-01-01 01:01:02 f9d5500c assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx      189 b-      189 stor 1981-01-01 01:01:02 19d3f940 assets/dexopt/baseline.profm
+ -rw-r--r--  0.0 unx  9282736 b-  3466876 defN 1981-01-01 01:01:02 66b0b0ed classes.dex
  -rw-r--r--  0.0 unx     2468 b-      999 defN 1981-01-01 01:01:02 afaef08f classes2.dex

A diff of the classes.dex seems to confirm that (that diff is rather big, so I did not include it here).
We'd appreciate if you could help making your build reproducible. We've prepared some hints on reproducible builds for that.
Looking forward to your reply!

@IzzySoft
I took a look at the recommendations for producing Reproducible Builds.
In these recommendations, it seems that some do not concern the application:

First Basic Rule
Fixed dependency versions
No funny build-time-generated IDs
API keys

I have some questions about some parts of these recommendations:

Clean Builds

How to automate this? Should this ./gradlew clean assembleRelease --no-build-cache --no-configuration-cache --no-daemon code be indicated somewhere?

JDK versions

In my build.gradle file it says:
compileOptions {    sourceCompatibility JavaVersion.VERSION_17    targetCompatibility JavaVersion.VERSION_17 }
In Android Studio settings, the Gradle JDK points to GRADLE_LOCAL_JAVA_HOME JetBrains Runtime 21.0.3 C:\Users… …
Is this a problem?

What I can do today (although I'm not sure if applying only this will solve the problem 🤔):

Compressing images

Nice, thanks!
Clean builds: if you use CI to build the app from the (tagged) commit, that should take care for it (wouldn't it usually run in a clean container?). If you build locally: yes, that's almost exactly the command we use with "flaky builds" (those with non-deterministic outcome, producing the "matching" result maybe every 3rd or 5th run, so we let the build run in circles until that "matching" result is achieved): making sure it's a clean tree and no artifacts remaining from previous builds are used. I've heard the equivalent in Android Studio would be running "clean" before "build".
JDK: your build.gradle specifies the minimum version needed: source requires at least JDK-17 to build, results need at least JRE 17 to run. So both conditions are met by JDK-21. Different JDK versions (the one you use and the one used by the rebuilder for your app) can produce different results, which is why we try to keep that in sync (and check with you if you might have upgraded when we get different results). And indeed, my build was done with JDK-17 – but that would not explain such a huge difference. But testing it again: the result is indeed different, though that doesn't change the RB status here as the source is different, too (see "local changes" above: your APK of 2.10 was not built from the commit the tag points to… but we're talking of old stuff here, I see there's a new release so let me check that now, with JDK set to 21.
Compressing Images: going by the above diff, you don't seem affected by that (graphics show separately usually – I'm not aware of graphics inside classes.dex.

Now let's see for 2.10.11:
  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 8a77e52d META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     2668 b-     2668 stor 1981-01-01 01:01:02 3bb5d7e3 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     2668 b-     2668 stor 1981-01-01 01:01:02 abd4a72f assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      189 b-      189 stor 1981-01-01 01:01:02 0445e85e assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  9278084 b-  3465238 defN 1981-01-01 01:01:02 eb20df91 classes.dex
+ -rw-r--r--  0.0 unx  9278088 b-  3465214 defN 1981-01-01 01:01:02 b82e816d classes.dex
  -rw-r--r--  0.0 unx     2468 b-      999 defN 1981-01-01 01:01:02 afaef08f classes2.dex

OK, embedded commit hash this time matches, classes.dex again is different. Dex diff is much smaller, though. Relevant part (just stripping "head and foot"):
-|: new-instance v2, Lcom/best/deskclock/widget/EmptyViewController;
-|: iget-object v3, v5, Lcom/best/deskclock/AlarmClockFragment;.mMainLayout:Landroid/view/ViewGroup;
-|: iget-object v4, v5, Lcom/best/deskclock/AlarmClockFragment;.mRecyclerView:Landroidx/recyclerview/widget/RecyclerView;
-|: invoke-direct {v2, v3, v4, v0}, Lcom/best/deskclock/widget/EmptyViewController;.<init>:(Landroid/view/ViewGroup;Landroid/view/View;Landroid/view/View;)V
-|: iput-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mEmptyViewController:Lcom/best/deskclock/widget/EmptyViewController;
+|: new-instance v0, Lcom/best/deskclock/widget/EmptyViewController;
+|: iget-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mMainLayout:Landroid/view/ViewGroup;
+|: iget-object v3, v5, Lcom/best/deskclock/AlarmClockFragment;.mRecyclerView:Landroidx/recyclerview/widget/RecyclerView;
+|: iget-object v4, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmsEmptyView:Landroid/widget/TextView;
+|: invoke-direct {v0, v2, v3, v4}, Lcom/best/deskclock/widget/EmptyViewController;.<init>:(Landroid/view/ViewGroup;Landroid/view/View;Landroid/view/View;)V
+|: iput-object v0, v5, Lcom/best/deskclock/AlarmClockFragment;.mEmptyViewController:Lcom/best/deskclock/widget/EmptyViewController;
 |: new-instance v0, Lcom/best/deskclock/alarms/AlarmTimeClickHandler;
 |: iget-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmUpdateHandler:Lcom/best/deskclock/alarms/AlarmUpdateHandler;
 |: invoke-direct {v0, v5, v8, v2}, Lcom/best/deskclock/alarms/AlarmTimeClickHandler;.<init>:(Landroidx/fragment/app/Fragment;Landroid/os/Bundle;Lcom/best/deskclock/alarms/AlarmUpdateHandler;)V
@@ -891519,10 +891520,10 @@
       catches       : (none)
       positions     :
       locals        :
-        0x0000 - 0x00e7 reg=5 this Lcom/best/deskclock/AlarmClockFragment;
-        0x0000 - 0x00e7 reg=6 (null) Landroid/view/LayoutInflater;
-        0x0000 - 0x00e7 reg=7 (null) Landroid/view/ViewGroup;
-        0x0000 - 0x00e7 reg=8 (null) Landroid/os/Bundle;
+        0x0000 - 0x00e9 reg=5 this Lcom/best/deskclock/AlarmClockFragment;
+        0x0000 - 0x00e9 reg=6 (null) Landroid/view/LayoutInflater;
+        0x0000 - 0x00e9 reg=7 (null) Landroid/view/ViewGroup;
+        0x0000 - 0x00e9 reg=8 (null) Landroid/os/Bundle;

I'm not sure what to make out of that: looks like the same "code" but assigned a different register? Btw: Building with JDK-17, the DexDiff gets much larger again, so JDK-21 already seems the best choice here at our side. Did you build this with Android Studio? Can you choose OpenJDK there instead of Jetbrains (just to check if that makes a difference, as it sometimes does with different "vendors")?

@IzzySoft
You're welcome.
JDK:

your APK of 2.10 was not built from the commit the tag points to…

I am very surprised that you say this because I always publish the application after the commit named "Update gradle, translations, version and fastlane" (or something very similar)

Did you build this with Android Studio?

Yes I did. I am using version 2024.2.1 Patch 2.

Can you choose OpenJDK there instead of Jetbrains

I can't currently do this because I'm using my company computer which prevents me from installing a lot of software.
As soon as I have repaired my personal computer (it will be done this week) I will provide you with an apk having taken care to choose Open-JDK and having launched "Clean" before "Build".

I am very surprised that you say this

Well, that's what the APK said. There's embedded version info (see the diff: META-INF/version-control-info.textproto) containing the commit hash. And the hash contained there was not the one the tag pointed to. :man_shrugging:

I can't currently do this because I'm using my company computer which prevents me from installing a lot of software.
As soon as I have repaired my personal computer (it will be done this week) I will provide you with an apk having taken care to choose Open-JDK and having launched "Clean" before "Build".

Fair enough, thanks a lot! I cannot even tell if the Jetbrain SDK is causing a difference there. But if we see nothing else, we need to rule that out (sometimes different SDKs cause differences).

@IzzySoft
Hi,
I didn't forget your request but some unforeseen circumstances prevented me from repairing my computer.
I should have time today to do so and should be able to provide you with an apk using Open-JDK.

Well, that's what the APK said. There's embedded version info (see the diff: META-INF/version-control-info.textproto) containing the commit hash. And the hash contained there was not the one the tag pointed to. 🤷♂

You're right... I must have been really tired for that to happen 😬

I must have been really tired for that to happen

I do know exactly what you mean – am there too often myself…

I should have time today to do so and should be able to provide you with an apk using Open-JDK.

Wonderful, looking forward to that, thanks! And on the risk of repeating myself: Please remember running "clean" before "build" in Studio. Studio tends to reuse artifacts from prior runs otherwise, I've been told.

@IzzySoft
I was finally able to do what you asked me; sorry again for taking so long.
As you can see on the screenshot below, I am using Open-JDK 17:

And below, an APK where I took care to do "Clean" before "Build" (This file was built from the the current latest commit e00a0d7):
Clock_2.10.1-release.zip

Hm, seems to be prety much the same. APK diff:
  -rw-r--r--  0.0 unx      120 b-      117 defN 1981-01-01 01:01:02 cd3e6b68 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     2651 b-     2651 stor 1981-01-01 01:01:02 2b9fd0d4 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx     2651 b-     2651 stor 1981-01-01 01:01:02 35a31afb assets/dexopt/baseline.prof
  -rw-r--r--  0.0 unx      189 b-      189 stor 1981-01-01 01:01:02 19d3f940 assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  9281136 b-  3465405 defN 1981-01-01 01:01:02 45b2cf3e classes.dex
+ -rw-r--r--  0.0 unx  9281144 b-  3465394 defN 1981-01-01 01:01:02 4236ef57 classes.dex
  -rw-r--r--  0.0 unx     2468 b-      999 defN 1981-01-01 01:01:02 afaef08f classes2.dex

And the dex:
 |: iput-object v0, v5, Lcom/best/deskclock/AlarmClockFragment;.mMainLayout:Landroid/view/ViewGroup;
-|: new-instance v2, Lcom/best/deskclock/alarms/AlarmUpdateHandler;
-|: iget-object v3, v5, Lcom/best/deskclock/AlarmClockFragment;.mContext:Landroid/content/Context;
-|: invoke-direct {v2, v3, v5, v0}, Lcom/best/deskclock/alarms/AlarmUpdateHandler;.<init>:(Landroid/content/Context;Lcom/best/deskclock/alarms/ScrollHandler;Landroid/view/ViewGroup;)V
-|: iput-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmUpdateHandler:Lcom/best/deskclock/alarms/AlarmUpdateHandler;
+|: new-instance v0, Lcom/best/deskclock/alarms/AlarmUpdateHandler;
+|: iget-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mContext:Landroid/content/Context;
+|: iget-object v3, v5, Lcom/best/deskclock/AlarmClockFragment;.mMainLayout:Landroid/view/ViewGroup;
+|: invoke-direct {v0, v2, v5, v3}, Lcom/best/deskclock/alarms/AlarmUpdateHandler;.<init>:(Landroid/content/Context;Lcom/best/deskclock/alarms/ScrollHandler;Landroid/view/ViewGroup;)V
+|: iput-object v0, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmUpdateHandler:Lcom/best/deskclock/alarms/AlarmUpdateHandler;
 |: sget v0, Lcom/best/deskclock/R$id;.alarms_empty_view:I
 |: invoke-virtual {v7, v0}, Landroid/view/View;.findViewById:(I)Landroid/view/View;
 |: move-result-object v0
 |: check-cast v0, Landroid/widget/TextView;
 |: iput-object v0, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmsEmptyView:Landroid/widget/TextView;
-|: new-instance v2, Lcom/best/deskclock/widget/EmptyViewController;
-|: iget-object v3, v5, Lcom/best/deskclock/AlarmClockFragment;.mMainLayout:Landroid/view/ViewGroup;
-|: iget-object v4, v5, Lcom/best/deskclock/AlarmClockFragment;.mRecyclerView:Landroidx/recyclerview/widget/RecyclerView;
-|: invoke-direct {v2, v3, v4, v0}, Lcom/best/deskclock/widget/EmptyViewController;.<init>:(Landroid/view/ViewGroup;Landroid/view/View;Landroid/view/View;)V
-|: iput-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mEmptyViewController:Lcom/best/deskclock/widget/EmptyViewController;
+|: new-instance v0, Lcom/best/deskclock/widget/EmptyViewController;
+|: iget-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mMainLayout:Landroid/view/ViewGroup;
+|: iget-object v3, v5, Lcom/best/deskclock/AlarmClockFragment;.mRecyclerView:Landroidx/recyclerview/widget/RecyclerView;
+|: iget-object v4, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmsEmptyView:Landroid/widget/TextView;
+|: invoke-direct {v0, v2, v3, v4}, Lcom/best/deskclock/widget/EmptyViewController;.<init>:(Landroid/view/ViewGroup;Landroid/view/View;Landroid/view/View;)V
+|: iput-object v0, v5, Lcom/best/deskclock/AlarmClockFragment;.mEmptyViewController:Lcom/best/deskclock/widget/EmptyViewController;
 |: new-instance v0, Lcom/best/deskclock/alarms/AlarmTimeClickHandler;
 |: iget-object v2, v5, Lcom/best/deskclock/AlarmClockFragment;.mAlarmUpdateHandler:Lcom/best/deskclock/alarms/AlarmUpdateHandler;
 |: invoke-direct {v0, v5, v8, v2}, Lcom/best/deskclock/alarms/AlarmTimeClickHandler;.<init>:(Landroidx/fragment/app/Fragment;Landroid/os/Bundle;Lcom/best/deskclock/alarms/AlarmUpdateHandler;)V
@@ -891542,10 +891544,10 @@
       catches       : (none)
       positions     :
       locals        :
-        0x0000 - 0x00e5 reg=5 this Lcom/best/deskclock/AlarmClockFragment;
-        0x0000 - 0x00e5 reg=6 (null) Landroid/view/LayoutInflater;
-        0x0000 - 0x00e5 reg=7 (null) Landroid/view/ViewGroup;
-        0x0000 - 0x00e5 reg=8 (null) Landroid/os/Bundle;
+        0x0000 - 0x00e9 reg=5 this Lcom/best/deskclock/AlarmClockFragment;
+        0x0000 - 0x00e9 reg=6 (null) Landroid/view/LayoutInflater;
+        0x0000 - 0x00e9 reg=7 (null) Landroid/view/ViewGroup;
+        0x0000 - 0x00e9 reg=8 (null) Landroid/os/Bundle;

I'm a bit clueless. Can you try ./gradlew assembleRelease at the command-line and see if sha256sum *.apk gives you a hash of 7b1380a980518cb0cfb950cf482935a65dc8152abd1981f8be7ea8c0411ab0b1 – just to rule out it's Studio making the difference here? That's the hash of the unsigned APK I get from my build with JDK-17 on debian:bookworm.

@IzzySoft
Not sure if this is correct but I prefer to specify the method used to obtain the hash value.
In the directory where the apk is, I opened a command prompt and typed : CertUtil -hashfile Clock_2.10.1-release-unsigned.apk SHA256 (I use Windows).
So I get: fcc8c8dd2fff8dfd7d63ef8e66092e1f7da00425f19b59eeed3b9246936be6a7

Yeah, according to this it should be the corresponding Windows command. OK, that does NOT match then either. Now I'm out of clues. Very last straw to pull on: do you get the same has on an APK build from a fresh clode (i.e. checkout the repo in a different place, cd into it, run gradlew assembleRelease there)? That then should rule out any .gitignored files and anything else that might have slipped into the "original tree" – and ensure you build on the very same source that I got.
I have never used Android Studio myself, so all I know about it is "second hand", sorry – but cleaning "everything" should not hurt: cached stuff could indeed play in here, and if "clean" does not take care for that… worth a try.

@IzzySoft
I'm afraid I didn't understand your request well.
If I run the command in another folder of the repository (for example in the "main" folder) and I run the command: gradlew assembleRelease here is the error message from the command prompt:
F:\ANDROID\DEVELOPER\STUDIOPROJECTS\Clock_BLACKYHAWKY\app\src\main>F:\ANDROID\DEVELOPER\STUDIOPROJECTS\Clock_BLACKYHAWKY\gradlew assembleRelease
Calculating task graph as no cached configuration is available for tasks: assembleRelease

FAILURE: Build failed with an exception.

* What went wrong:
Project directory 'F:\ANDROID\DEVELOPER\STUDIOPROJECTS\Clock_BLACKYHAWKY\app\src\main' is not part of the build defined by settings file 'F:\ANDROID\DEVELOPER\STUDIOPROJECTS\Clock_BLACKYHAWKY\settings.gradle'. If this is an unrelated build, it must have its own settings file.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 1s
Configuration cache entry stored.

I must have made a mistake and I apologize for it as I am not used to using this kind of command.
Finally, to clarify this topic, what should I get on my side to know if the Reproducible Builds are compliant? I'm a bit lost... 🤔

If I run the command in another folder

Nonono. OK, let me be more details. Assuming your code currently resides in C:\Users\BlackyHawky\Projects\Clock:
cd C:\Users\BlackyHawky\Projects
mkdir test
cd test
git clone -b 2.10.1 https://github.com/BlackyHawky/Clock.git
cd Clock
gradlew assembleRelease

I.e. check out a fresh copy of your project into a clean place (so you get exactly the same code I have here) and build from that. The above gives you a clean tree at the 2.10.1 tag. Then, tell me the sha256 hash of the resulting, unsigned APK.
To your "Edit 1": unfortunately, no. To "Edit: 2": that should not affect classes.dex but the contents of the res/ folder, AFAIK. And I guess, like PNG crunching, resource shrinking is not deterministic (i.e. it produces different results each time you run it) which is why it doesn't go well with RB. See also here for details; I've no idea why they had to explicitly disable it, it seems the default is "disabled".

how do I know if it's ok without me asking you?

I cannot tell. In many cases I, too, only know when I see the results…

Question, are there issues for recent Android versions if apps are built with the lowest possible JDK?

To my knowledge, JDK should not be relevant for that (only targetSDK AFAIK). But at our builders, we can use JDKs 11, 17 and 21, so there'd be no problem going with 21 if you want to. Though it would be nice if you could confirm the APK checksum with JDK-17 and the "separate clone" first :wink:

@IzzySoft
I will do the test tonight (Paris local time).
By the way, I have to do the test again because what I provided you did not point to the commit of version 2.10.1 (15a6c92) but to the last commit (e00a0d7); this is certainly why we find inconsistencies.

META-INF/version-control-info.textproto from my APK with the hash 7b1380a980518cb0cfb950cf482935a65dc8152abd1981f8be7ea8c0411ab0b1:
repositories {
  system: GIT
  local_root_path: "$PROJECT_DIR"
  revision: "e00a0d711f9a4aa606c0d43c5c72ee24c741d086"
}

Yes, built from e00a0d7, right. Mine too.

@BlackyHawky how many CPU cores do you use when building? This could have something to do with it (see https://issuetracker.google.com/issues/366412380). I've now run builds with 16, 8, 6, 4 and 2 cores, each produce a different APK (could as well be a non-deterministic build (aka "shaky build") in general, should maybe try our "unshaker", will report if that did something). Knowing your number-of-cores would increase our unshaking chances.

@IzzySoft
I'm using 4 cores (Hyper-Threading disabled)

Thanks to having multiple builders now, I've utilized them both to run one with 4 and one with 8 cores at the same time (we can set the number of cores in our recipes). I've let the build run in a loop. Both produced 10 times the same hash, though none of them matching yours – and not matching each other. So it's definitely something with cores, but probably not only.

As stated in stackoverflow here, this can be set in the local.properties file.

Oh, nice – didn't know that! Looking at the official documantation at Gradle Build Environment Documentation:

org.gradle.parallel=(true,false): When configured, Gradle will fork up to org.gradle.workers.max JVMs to execute projects in parallel. Default is false.

and

org.gradle.workers.max=(max # of worker processes): When configured, Gradle will use a maximum of the given number of workers. Default is the number of CPU processors.

So the latter would make sense to be set to what your "official builds" have. But: Running with 4 cores, the diff here gets even bigger. Additionally to baseline.prof and classes.dex, also baseline.profm differs and the dex diff is twice as large. Same if I run with 8 cores. So this does not give us progress.
Was woth a try. Luckily I covered the number of cores you really used, so we can say that does not help – at least not that alone. Something else we might have missed?
And should you want to give those gradle settings a try: the hash of the unsigned APK for my builds were:

7b1380a980518cb0cfb950cf482935a65dc8152abd1981f8be7ea8c0411ab0b1 (no core specification)
04ad163e8ddb29f8702e5d1c4ff5c2ce0a17acb30700c88dbfde54d8cf76cd67 (8 cores)
8c5bc45b09f62f71503c75dcc43235aaeb0aa093d19126aa0b06a1ce8b984044 (4 cores)
3496e8a9c64f225aa8f1dc610ce33b9d03f6ba71c074b7e010dd6b67d7684af8 (2 or 6 cores, don't remember)
be252da84c44b7061fab77866cdf584dd561026e16ef8540160e9d91385b31da (6 or 2 cores I guess)

Tried to many, should have taken notes…

PS, if you want to try it in a loop to see if some setting hits that and if it always produces the same hash:
set +x
PROF_FILE=app/build/intermediates/binary_art_profile/release/compileReleaseArtProfile/baseline.prof
PROF_SHA1=6dc56cefc57875c10bdafb34c9ba4f4d4384a424
for _ in {1..10}; do
  ./gradlew clean assembleRelease --no-build-cache --no-configuration-cache --no-daemon
  if [ "$( sha1sum "$PROF_FILE" | cut -d' ' -f1 )" = "$PROF_SHA1" ]; then
    break
  fi
done

@IzzySoft
I think I have some good news for you.
If I apply this without ever opening Android Studio:

Nonono. OK, let me be more details. Assuming your code currently resides in C:\Users\BlackyHawky\Projects\Clock:
cd C:\Users\BlackyHawky\Projects
mkdir test
cd test
git clone -b 2.10.1 https://github.com/BlackyHawky/Clock.git
cd Clock
./gradlew assembleRelease

The hash you get is identical to the one you found with 4 cores.
8c5bc45b09f62f71503c75dcc43235aaeb0aa093d19126aa0b06a1ce8b984044

@IzzySoft
I understood the difference in the hash value that there was between our 2 versions. It is simply the commit on which our apk pointed. (My created apks were pointing to the very latest commit I published instead of pointing to the commit of version 2.10.1 because I thought it was the same for you).
Indeed, in my default folder, if I apply from Android Studio ./gradlew assembleRelease after having done Clean, the hash I get is identical to the one you found with 4 cores (8c5bc45b09f62f71503c75dcc43235aaeb0aa093d19126aa0b06a1ce8b984044).
In summary, I think we can conclude:

Building with the same number of cores;
Do "Clean" before "Build";
Lastly (maybe) use Open-JDK 17;

Am I right, do you think?
Below is the apk if you need it:
Clock_2.10.1-release-unsigned.zip

Great to see we've solved the riddle! Full ack to your "marshal plan". May I suggest we do a test run for that, to get the shield up?

you prepare 2.10.2 release but do not tag it yet
build the APK from that commit as your "marshal plan" outlines (make sure there are no uncommitted changes in your tree (git status), JDK-17, use 4 cores, first "clean" then "build")
you attach the APK here and name the commit along
I use that to make an RB run, and let you know the results

If it works out, you'd just need to tag that commit, make it a release, and attach the APK to that. With that in place, I'd then establish Clock in my builder.

@IzzySoft
I will do it tonight (or Sunday in the worst case) because I need my personal computer.
Quick questions:

do you think it is necessary to add org.gradle.workers.max=4 in the "gradle.properties" file?
do we agree that i can include the latest published commits (this is certainly what you meant in this sentence: "build the APK from that commit as your "marshal plan" outlines..." ; I want to be sure I understand your sentence correctly.?

Thanks! As for your points:

I don't think it is necessary – I guess even when built with 32 cores it will produce a working APK. It might be worth a try, though, if that makes it RB without the need of specifying the number of cores in our recipes.
Yes. What was meant is: "build from a clean tree at the commit (the tag points to)" (terms in parenthesis for the later release builds). APK and commit must be the same match on your side and ours. And "clean" because – well, as we just figured, right? :wink: It's also the "first basic rule" in our hints on reproducible builds btw.

@IzzySoft
Below is the apk of the new version:
Clock_2.11-release.zip
Commit: 77dace9b3e82de24a0674b975d047b69f85c1c50
Hash: 4cc2369392afa4b71fa1c197f7b617f14588f3785e0f88411f5c71b8e1342ca8
I'm keeping my fingers crossed that everything will run properly.

First try, without nailing it to any fixed CPU number: still the old problem, not RB.
Second try, nailing it to 4 cores: different hash, but still the same issue (dex diff looks like the one above). And it seems to be always com/best/deskclock/AlarmClockFragment – at least that is "constant" and "reproducible" (the error, not the APK).
I gave it a last try with JDK-21, but then the dex diff gets huge. :cry:

@IzzySoft
I am really disappointed because I followed all the recommendations. 😭
Could this be from Android Studio?
Maybe there is a difference between "Build" in the Android Studio menu and the "./gradlew assembleRelease" command?

What about building on the commandline (./gradlew clean assembleRelease)? I have no idea about where Studio might leave and use "previous stuff" like artifacts etc as I never use it. It's not the signing that makes the difference here, but the building.

@IzzySoft
I get the same apk with the same hash value. I really don't understand what's wrong. 😭

Maybe it's the fact that I'm using Windows? See issue here on issuetracker.google.com.

I'm clueless now. Thought we had nailed it to be the "number of cores" issue. I can try another time if it's the "flaky build" issue as well (running that now)… Nope, each round the same hash.

Maybe it's the fact that I'm using Windows?

:eyes:
Sounds like it. And that issue is from Fay, who confirmed it for multiple gradle versions. Well, sounds like it then, doesn't it? Any chance you could build on Linux (if you don't have a Linux machine/VM yourself, maybe using Github CI)?

@IzzySoft
Yesterday, you said:

And it seems to be always com/best/deskclock/AlarmClockFragment

So I mainly modified this file and the linked xml file; then I did a "force-push" to overwrite the previous commit.
So can you do a new test please?
Below is the apk of the new version:
Clock_2.11-release.zip
Commit: 1d7f2f8408954cd1fab58f6ffce1ae4f98cbcc83
Hash: dbbde31d72c10d2d758ff28a4188cd5aa624e563eb597e503192df912030764c

Oof, that's not the only thing you changed, huh?
Configuration cache entry stored.FAILURE: Build failed with an exception.

* Where:
Build file '/build/repo/app/build.gradle' line: 20

* What went wrong:
A problem occurred evaluating project ':app'.
> /build/repo/keystore.properties (No such file or directory)

OK, working around that:
- echo -e "storeFile=/dev/null\nstorePassword=storePass\nkeyAlias=alias\nkeyPassword=keyPass" > keystore.properties
- sed -r '/signingConfigs.release/d' -i app/build.gradle

OK, build succeeds, but output file name has changed as well (so it failed to be copied out of the container for comparison), another round then…
Wow. I didn't limit CPUs, just to check – but it seems this did the trick:
    "upstream_signed_apk_sha256": "dbbde31d72c10d2d758ff28a4188cd5aa624e563eb597e503192df912030764c",
    "built_unsigned_apk_sha256": "27f444343099a14e5323f220455ca69a02f685dafa54cced3354b58dbf89b2ec",
    "signature_copied_apk_sha256": "dbbde31d72c10d2d758ff28a4188cd5aa624e563eb597e503192df912030764c"

That means this was RB :partying_face: Congrats! What a ride, though :see_no_evil:
Going for the release then? :smiley:

@IzzySoft

Oof, that's not the only thing you changed, huh?

OK, build succeeds, but output file name has changed as well (so it failed to be copied out of the container for comparison), another round then…

Indeed, to be able to sign the apk using the command lines, I modified the "build.gradle" file by taking inspiration from this link. (Not sure if this is a correct method but it is very simple to implement and works correctly).
I also took the opportunity to change obsolete parameters, especially for the output file name.
Thank goodness you were able to adapt to these changes! 💪
Finally, I am very happy to see that my modification made in the "AlarmClockFragment.java" file was able to resolve this issue in the classes.dex. 🎉
Thank you for trusting me and and thank you for persevering with all these tests! 🎉💪👍👌

Going for the release then? 😃

If I'm not too tired after finishing my job I will do it later, otherwise tomorrow with my personal computer. 😉

@IzzySoft

Just to make sure: not saying you must change it, recipe is working now. Just sharing what I've learned on the topic, by having processed 367 successfully RB recipes in my builder alone 😜 So keep yours as it is if it works for you, and maybe stow away these details for… well, something in the future?

If you don't mind, I wish we could fix this topic in the “build.gradle” file; indeed, even if it works for me (because I have the "keystore.properties" file), I am not a fan of this modification.
Also, it would require a very small modification that I should have thought of before (but I was pressed for time because of my job) ; I just have to write:
    if (keystorePropertiesFile.exists()) {
        keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
    }

    signingConfigs {
        release {
            if (keystorePropertiesFile.exists()) {
                storeFile = file("$rootDir/keystore.jks")
                storePassword = keystoreProperties["storePassword"]
                keyAlias = keystoreProperties["keyAlias"]
                keyPassword = keystoreProperties["keyPassword"]
            }
        }
    }

Or else I totally remove this modification about signingConfigs now that I know that building the apk from the Android Studio menu works just fine as before. 🤔
When you think about it the 2 main problems were the different number of cores in our processors and the "AlarmClockFragment.java" file.

Sure, take a break – well earned! Just give me a ping please once it's there. I'd then do a last test run, and then add the recipe to the builder and report back, so we can close this issue.

I think I'll do this tonight because I'm excited that we're finally validating our app as Reproducible Builds. 😉

Fine with me! If you make that modification, please don't forget to try
signingConfig signingConfigs.findByName("release")

(if that works there; I always get confused by what works in build.gradle and what might require build.gradle.kts – where this then would need to be signingConfig = signingConfigs.findByName("release")). And let me know your decision; I might need to add a marker in the YAML to manually adjust the recipe before the next run.

because I'm excited that we're finally validating our app as Reproducible Builds

Hehe – and so am I!

@IzzySoft
I'm not at all an expert when it comes to the "build.gradle" file but using signingConfig signingConfigs.findByName("release") doesn't seem to have any impact. So I included it in my change that allows the "build" without the "keystore.properties" file; in this case we obviously have an unsigned version.
We should note that the output name of the file agrees according to the build type:

build type "Release" with the "keystore.properties" file → Clock_2.11-release.apk
build type "Release" without the "keystore.properties" file → Clock_2.11-unsigned.apk
build type "Debug" → Clock_2.11-debug.apk

Like yesterday, I did a force-push to overwrite the old commit.
I hope that on your side, you won't have to adapt too much what you've already done and that it will (finally) be perfect. 😉
Below is the apk of the new version:
Clock_2.11-release.zip
Commit: 9613c72d902c181db905b0c9b88d48c8afff8ba7
Hash: 596f01dafca8e88b2a7220b55b86173172b1f2ee03fbd97cf9355b1e999a5074

    "upstream_signed_apk_sha256": "596f01dafca8e88b2a7220b55b86173172b1f2ee03fbd97cf9355b1e999a5074",
    "built_unsigned_apk_sha256": "41398898f743a1060796b81330936e105dd869e1f36e11c9184a710c15e9cf66",
    "signature_copied_apk_sha256": "596f01dafca8e88b2a7220b55b86173172b1f2ee03fbd97cf9355b1e999a5074"

with the simplest possible recipe:
build:
  - chmod +x gradlew # just to make sure, might not even be needed
  - ./gradlew assembleRelease

Done & RB.

Great news!!! 🎉🎉
I'll be releasing the new version shortly. I'll let you know when it's done.

@IzzySoft
It's done! 🎉🎉

BUILD SUCCESSFUL in 2m 26s
41 actionable tasks: 41 executed
Configuration cache entry stored.
+ mv app/build/outputs/apk/release/Clock_2.11-unsigned.apk /outputs/unsigned.apk

--- END BUILD LOG ---
Keeping '596f01dafca8e88b2a7220b55b86173172b1f2ee03fbd97cf9355b1e999a5074-com.best.deskclock-2.11-upstream.apk'...
Keeping '41398898f743a1060796b81330936e105dd869e1f36e11c9184a710c15e9cf66-com.best.deskclock-2.11-unsigned.apk'...
Reproducible: True
Tags built: 1.

It's done here, too – so 2.11 will arrive at the repo with the next sync around 7 pm UTC, and with the green shield up :partying_face:
:raised_hands:


User connection details aren't updated

User connection details aren't updated when user resource is updated.

fixed with https://github.com/edgefarm/provider-natssecrets/commit/5ec09ea073ffa4cb610b9883641b45a6ed704161


Zip Compression Failing On UNC

I'm aware that this may be a result of flaky UNC share, but when Driver automation Zips the Drivers over to the UNC path it fails on one or two attempts (out of 40+ models) and completely locks up Driver Automation tool.
Is there any chance we can perform the zipping function locally and do a file copy of the zip when we choice the driver compression option?
I may be seeing another issue caused by this where the powershell tool unzipping the driver zip fails and then it deletes all the drivers. I think this is only effecting the drivers for the models that Driver Automation tool crashes on....
I'm rebuilding my drivers without Zip compression for now, though I really like the speed of data transfer when used!
Awesome Job as usual!

I do all processing locally on the server and have set "D:\DAT" as download location.
After the download, extraction and zipping process is done, the files are copied to the appropriate share for further processing into ConfigMgr.
I've also had some issues when file path is more then 256 characters during extraction process. Some parts of the process is done under the installation directory of DAT. So I moved the installation directory to "C:\Program Files\DAT\DriverAutomationTool.exe" and this mitigates that issue.

Thanks HermanGB,
Moving my installation directory to C:\Program Files\DAT resolved my issue with zip compression that previously failed to complete.


tabs: what's the idea behind tabHeadingTransclude?

I'm trying to understand the way you've created the tabs and I don't quite get why is tab heading and tab content being transcluded this way? The heading especially, given there's both tabHeadingTransclude and {{ heading }}..
Could you break down the code a little for me, please?

Might get a quicker response asking this Question on SO or in the IRC channel (GitHub is primarily for issue tracking.)

Closing as this isn't a description of an issue.


feat(user): PRTL-278 dl refresh token (#1081)

& fix error in error handler

this is exactly the same as the https://github.com/NCI-GDC/portal-ui/pull/1081 on active


Potential fix for network/config API changes

[x] Add missing namespace for network interfaces
[x] Return config sample to retrieving config values

@patridge Apologies but forgot all about this PR. If the changes are not in yet, can you update so we can merge it? thanks!

I've forgotten about it too. Let me merge it up to date and make sure it is still valid. Those APIs were pretty fluid when I did this PR.

Merge conflict is fixed, but I haven't tested this again yet. (I don't even remember what triggered the issue that lead to the PR anymore.)

I've realigned the C# and VB WiFi_Basics samples, which had drifted a bit in what they did. That also involved updating C# to use Resolver.Log.* all over.

I am getting some ioctl GetSetConfigurationValue failed OperationNotPermitted logging when running the Config_Files sample on a Feather board with the latest preview OS and latest local dev repos.
[1/25/2023 09:20:24] Meadow StdOut: =========================OutputMeadowOSInfo============================
[1/25/2023 09:20:24] Meadow StdOut: OS version: <IP_ADDRESS>
[1/25/2023 09:20:24] Meadow StdOut: Mono version: <IP_ADDRESS>
[1/25/2023 09:20:24] Meadow StdOut: Build date: 23 Jan 2023 20:01:01 UTC
[1/25/2023 09:20:24] Meadow StdOut: =======================================================================
[1/25/2023 09:20:24] Meadow StdOut: ====================OutputDeviceConfigurationInfo======================
[1/25/2023 09:20:24] Meadow StdOut: Automatically connect to network: True
[1/25/2023 09:20:24] Meadow StdOut: Get time at startup: True
[1/25/2023 09:20:24] Meadow StdOut: ioctl GetSetConfigurationValue failed OperationNotPermitted
[1/25/2023 09:20:24] Meadow StdOut: Configuration ioctl failed, result code: 1
[1/25/2023 09:20:24] Meadow StdOut: Default access point: False
[1/25/2023 09:20:24] Meadow StdOut: Maximum retry count: 7
[1/25/2023 09:20:24] Meadow StdOut: ioctl GetSetConfigurationValue failed OperationNotPermitted
[1/25/2023 09:20:24] Meadow StdOut: Configuration ioctl failed, result code: 1
[1/25/2023 09:20:24] Meadow StdOut: Maximum retry count: False
[1/25/2023 09:20:24] Meadow StdOut: =======================================================================

Those ioctl errors were issues with my code in how it is retrieving config values. I'll update with my latest changes and the PR should be ready for review again.


Fix deprecation warning with scikit-learn 0.21

sklearn.externals.joblib is deprecated in 0.21 and will be removed in 0.23.
This change uses the joblib library directly, if available; Otherwise it falls back to sklearn.externals.joblib, which seems like the least intrusive way of making this change.

Hello @jamesmyatt! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file umap/umap_.py:

Line 18:80: E501 line too long (80 > 79 characters)

Coverage increased (+0.008%) to 94.544% when pulling 3b966972a45ea2e4c88cb821bbb372d7f8faee2e on jamesmyatt:bugfix/joblib_import into b3816672c74f7963a79ad69186da60469484c14c on lmcinnes:master.

Failure in https://travis-ci.org/lmcinnes/umap/jobs/533380248 is unrelated to this PR.

Thanks -- I was just dealing with this in hdbscan, but hadn't looked at umap recently.


Pre-release handling

What you want to add
It's not clear how this behaves with pre-releases, so it'd be great to see a documentation update, but the best outcome would be an input for whether or not to include pre-release tags.
Why this is needed
The latest tag someone wants may or may not be a pre-release version, e.g. 0.5.0 vs 1.0.0-beta.1 - which would be returned?

I just ran into this problem today (what a coincidence), I am trying to use this action for pre-release tags but it does not seem like the grep expression matches pre-release versions.

I think it does match but I want to the opposite behaviour for my own purposes. Not tested it yet but looks easy to change

@roborourke @zischknall problem is this is running using -E  and this doesn't support lookaheads and lookaheads and lookbehinds.
This should be replaced with -P


Run bundler in a seperate shell as we do in bash shell.

Here exist two ruby:

~/traveling-ruby/bin/ruby, this ruby is independent from the ruby for project.
it is isolate with any other ruby completely.

project specially ruby, which is manager by RVM.

Basically,  what i want to do is:
~/traveling-ruby/bin/ruby -e 'system "bundle list"'

But it not worked.
Gems included by the bundle:
Could not find rake-12.0.0 in any of the sources

But, i think it should't, becase if invoke with a bash, it always work.
Back to my problem, I use capistrano globally, bundle with a travelling ruby.
all my project use same capitrano, it work well.
But, when I want to run bundle locally, issue is happen.
namespace :deploy do
  task :some_task do
    system 'bundle list'
  end
end

I am so weired about:
I can run bundle list in a bash shell script, as follow
x=$(bundle list)
# or x=`bundle list`
echo "$x"

But, use a seperate ruby, to run bundle list, not work. why?
Thanks

I think, we just use difference approach to load bundle list in current sub shell.
one approach is use ruby's system invoke, another is ``bash invoke```. load if success, only dependent the ruby for current project, whatever you use  a bash or another ruby`.
we should got same result, right?

I don't think this is a Capistrano issue, and I don't fully understand your question, but my hunch is that you are running into this problem:
When you run a  bundle subprocess from within Ruby (which may have its own existing Bundler environment), this causes unexpected behavior.
From Bundler's documentation:

Any Ruby code that opens a subshell (like system, backticks, or %x{}) will automatically use the current Bundler environment. If you need to shell out to a Ruby command that is not part of your current bundle, use the with_clean_env method with a block.

Therefore, I would try this:
namespace :deploy do
  task :some_task do
    Bundler.with_clean_env do
      system 'bundle list'
    end
  end
end

The important part is Bundler.with_clean_env.

@mattbrictson , Hi, I tried this answer before, it not worked.
seem like it not isolate two version ruby completely, rake version error.
Gems included by the bundle:
Could not find rake-12.0.0 in any of the sources

I just want to use shell (system 'bundle list') to run one command in that directory,
I don't know why we need care about this ruby's bundler or rake version ...
could you explain more about this? I thought it should't happen.
thanks

The only care about is system function which defined in Kernel module in ruby.
I wonder if change to another language (e.g. python), use that language system
invoke, what happen?
thought from another inspect. capistrano should be a general deployment tools.
it should just worked as invoke in terminal. all project use one seperate copy
capistrano should just work. (in fact, before run bundler locally, it work quite well)
maybe there exist a alternative for system function, could seperate father ruby process (which run
capistrano) from child process(run project bundle) completely?

Sorry, I am having a hard time understanding your question. Perhaps take this to Stack Overflow instead? We try to keep GitHub issues limited to bug reports. This sounds more like general troubleshooting/how-to.

GitHub issues are for feature requests or bug reports. Since this is more of a how-to question, I am closing this issue. The Capistrano team recommends you use Stack Overflow for general questions. For more details, please see our contribution policy.

This is a issue about bundler not work in another ruby process system call.

Any Ruby code that opens a subshell (like system, backticks, or %x{}) will automatically use the current Bundler environment.

Why don't think this is a bug?

Oops, I just now realized this issue is in the bundler/bundler repo. I thought was capistrano/bundler (I am a capistrano maintainer).
I should let the actual bundler maintainers answer this question, not me. 😅

@mattbrictson , Yes, after those discuss, i think this maybe a bundler issue.
But, I don't rule out may be capistrano/bunder problem.

Sorry, I am having a hard time understanding your question. Perhaps take this to Stack Overflow instead? We try to keep GitHub issues limited to bug reports. This sounds more like general troubleshooting/how-to.

Agreed

maybe there exist a alternative for system function

Bundler.clean_system

Bundler.clean_system

This same as Bundler.with_clean_env,  when invoke rake, it use project rake,
not cap builtin version ruby rake. not work.


Mistake in Takanohara Weekday Schedule

This schedule was wrong for a while and I missed the bus because of this hehe

🙇 🙇


Cannot use console.log debugging in onBeforeHandle()

What version of Elysia.JS is running?
1.0.0-rc.19
What platform is your computer?
Linux 6.6.21-1-lts x86_64 unknown
What steps can reproduce the bug?
Create a middleware with onBeforeHandle(). Using bearer as example:
export default new Elysia()
  .use(bearer())
  .onBeforeHandle(({ bearer, set }) => {
    console.log(bearer)
    if (!bearer) {
      console.log(bearer)
      set.status = 'Unauthorized'
      return "Unauthorized"
    }
  })
  .resolve({ as: 'global' }, ({ bearer }) => {
    const user = bearer === "booyah" ? { name: "Nishant" } : null
    return { user }
  })

What is the expected behavior?
Allow console.log to work on functions like onBeforeHandle().
What do you see instead?
I do not see any console.log output of the bearer token, despite having sent one.

Additional information
No response

In version v0.8.17, the problem no longer persists. I can view console.log originating from the middleware. Here is the output with the version.

Issue was because I was not calling a route that existed as a test subject.


TOMEE-2698: Translate to spanish simple-rest

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?


这个代码块少了一个缩进

经过测试确实是个问题

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Validate before update in component?

I'm trying to validate input (w/ vuelidate) and need to stop a commit from happening if it fails.  I see where I can write a custom mutation, but that doesn't have access to the validation object I need.
Is there component-level access to override the computed get/set methods?

You can pass whatever you want into a mutation as a parameter. I'm not sure what you mean by component-level access. The examples show how you can build your own custom mutation.

Closing this as there's been no further feedback from the OP


[PACT-724] Added the JMS Request / Reply Client.

Integration tests are working with success scenarios. Just a few minor suggestions:

adding inline comments (from the original jms4s-request-reply) would be helpful for understanding the code and usage of cats effect better.
adding error scenarios in Integration tests for eg. incorrect queue or service id  unless there is never the possibility for this

adding inline comments (from the original jms4s-request-reply) would be helpful for understanding the code and usage of cats effect better.

I didn't find they added much, but am open to restoring them. @rwalpole ?

adding error scenarios in Integration tests for eg. incorrect queue or service id unless there is never the possibility for this

Agreed - I could have added a number of such scenarios; but I understood the task as relocating the code from the original repo with minor changes.


File response should accept byte stream and media_type as an alternative to file path.

What's the feature you'd like to ask for.
As of v1.18.1: Starlite's File response only supports returning existing files.
return File(
        path=Path(Path(__file__).resolve().parent, "report").with_suffix(".pdf"),
        filename="repost.pdf",
    )

However, it should be able to support returning files directly from byte streams such as BytesIO. This would enable apps that can't use filesystem (eg. Google App Engine) to return files without much workaround.
In addition to that, File response should optionally accept media_type as it is quite useful to set it dynamically depending on the file content.
Therefore, we should be able to return file by passing data and media type to File class like:
...
data = io.BytesIO()
... do something data..
return File(
        content=data,
        filename=filename,
        media_type='application/vnd.ms-excel',
        headers={f'Content-Disposition': f'attachment; filename={filename}'},
    )

❤  Thank you very much :)

Would a streaming response be what you are looking for here?
"""Minimal Starlite application."""
import io

from starlite import Starlite, get
from starlite.datastructures import Stream
from starlite.enums import MediaType

@get("/", media_type=MediaType.TEXT)
def hello_world() -> Stream:
    byte_stream = io.BytesIO(b"some byte string")
    """Hi."""
    return Stream(iterator=byte_stream)

app = Starlite(route_handlers=[hello_world])

Nope, I solely meant using stream as source for file download.

Sure but when it boils down to it, FileResponse is streaming chunks of bytes just like StreamingResponse does:
From FileResponse:
            async with await anyio.open_file(self.path, mode="rb") as file:
                more_body = True
                while more_body:
                    chunk = await file.read(self.chunk_size)
                    more_body = len(chunk) == self.chunk_size
                    await send(
                        {
                            "type": "http.response.body",
                            "body": chunk,
                            "more_body": more_body,
                        }
                    )

And from StreamingResponse:
        async for chunk in self.body_iterator:
            if not isinstance(chunk, bytes):
                chunk = chunk.encode(self.charset)
            await send({"type": "http.response.body", "body": chunk, "more_body": True})

        await send({"type": "http.response.body", "body": b"", "more_body": False})

Say we added a content attribute to File we'd have to produce a StreamResponse from it anyway, unless we wrote the stream to a temporary file before passing it to FileResponse, which I dont think is the way to go.
Also setting headers and media type on the responses is possible if you want to drop down a leve and call the to_response() method:
"""Minimal Starlite application."""
import io

from starlette.responses import StreamingResponse
from starlite import Starlite, get, Request
from starlite.datastructures import Stream
from starlite.enums import MediaType

@get("/", media_type=MediaType.TEXT)
def hello_world(request: Request) -> StreamingResponse:
    byte_stream = io.BytesIO(b"some byte string\n\n")
    """Hi."""
    return Stream(iterator=byte_stream).to_response(
        headers={f"Content-Disposition": f"attachment; filename=my-file"},
        media_type="application/vnd.ms-excel",
        status_code=200,
        app=request.app,
    )

app = Starlite(route_handlers=[hello_world])

Issue with that though is that we lose the openapi docs when we return the starlette response directly.

Thanks a lot for the tip I managed to get it done as well
(https://github.com/denizkenan/starlite-hello-world)
curl localhost:8000/greetings
I fully agree with you. It is just better dx to handle this purely within starlite using File response. I don't think it is super edge case for us to use lower level APIs.

So if we made media_type configurable on ResponseContainer so you could do this:
"""Minimal Starlite application."""
import io

from starlite import Starlite, get
from starlite.datastructures import Stream
from starlite.enums import MediaType

@get("/", media_type=MediaType.TEXT)
def starlite() -> Stream:
    byte_stream = io.BytesIO(b"some byte string\n\n")
    """Hi."""
    return Stream(
        iterator=byte_stream,
        headers={f"Content-Disposition": f"attachment; filename=my-file"},
        media_type="application/vnd.ms-excel",
    )

app = Starlite(route_handlers=[starlite])

Would that be the solution you are looking for?


Warden 0.8.0 on Ubuntu - Nginx/Varnish Exit Early

Base OS: Ubuntu 20.04.1 LTS
Docker Version: 19.03.9, build 9d988398e7
Docker Compose: 1.25.4, build 8d51620a
Warden Version: 0.8.0
Warden Environment Type: magento2
Background
Following an upgrade from 0.6.0 to 0.8.0, projects that were working using warden, "broke." When running warden env up / warden env start ( equivalent to running docker-compose up ), the nginx container exits immediately, and so does the varnish container.
Findings

docker logs <nginx-container-id> shows the following:

2020/07/29 21:47:23 [emerg] 1#1: invalid number of arguments in "fastcgi_param" directive in /etc/nginx/fastcgi_params:28
nginx: [emerg] invalid number of arguments in "fastcgi_param" directive in /etc/nginx/fastcgi_params:28

This is the location of line 28 referenced above, which has the following declaration:
fastcgi_param  HTTP_X_DEBUG_HOST  ${XDEBUG_CONNECT_BACK_HOST};

This is where there was a change between 0.6.0 and 0.8.0 releases. XDEBUG_CONNECT_BACK_HOST

Due to this depenency from the varnish container, upon the nginx container, is why the varnish container is also exiting immediately.

Conclusion
It's clear to me that the host.docker.internal works on Mac, but not on Linux.
A few quick fixes in order to get around the nginx and varnish containers from exiting early:

I've just deleted this and the next line ( since I install warden via git clone ).
Or, I've applied the following diff:

diff --git a/environments/includes/nginx.base.yml b/environments/includes/nginx.base.yml
index 206cfdc..6f95b46 100644
--- a/environments/includes/nginx.base.yml
+++ b/environments/includes/nginx.base.yml
@@ -13,4 +13,4 @@ services:
     volumes:
       - .${WARDEN_WEB_ROOT:-}/:/var/www/html:delegated
     environment:
-      - XDEBUG_CONNECT_BACK_HOST=${XDEBUG_CONNECT_BACK_HOST:-}
+      - XDEBUG_CONNECT_BACK_HOST=${XDEBUG_CONNECT_BACK_HOST:-""}

@davidalger I can open a PR for the above diff, if you'd like, but I wanted to wait and see if you had something better in mind.
Just sharing this so that if anyone else runs into it, and there's no need for anything from 0.7.0+, switching to 0.6.0 or following any of the suggestions in the previous sentence, will get things going again.

@ryantfowler Thanks so much for the thorough and accurate write up. This issue is certainly a regression and crept in due to PR #199 which was intended to allow XDEBUG_CONNECT_BACK_HOST to be set via an exported environment variable so that (in lieu of having automatic setting) it can be configured on WSL1, but also when using Warden on networked Linux dev servers rather than on the same host as the workstation.
The patch you noted would be the appropriate solution. In fact '' is the default value for the env var in the Dockerfile for the nginx image. :)
I'll be pushing out release 0.8.1 with this fix very shortly.

@davidalger you're most welcome, and thank you for the quick turn around on this. I also appreciate the explanation, which provides more context for the changes.


EIP-6110: Add deposit validation and apis

PR description
This PR is the continuation of #5055. It is the final PR for EIP-6110. The following are the main features introduced:

Decode and extract deposit from transaction receipt log
Introduce depositContractAddress field in genesis file
Validate deposits in a block against the transaction receipt logs
Update engine_newPayloadV2 and engine_getPayloadV2 according to the spec. Some of the non-functional components were partially implemented in the previous PR

Fixed Issue(s)

#5004
Testing

[x] Local block production pre-V6110
[x] Public testnet sync
[x] Public mainnet sync

To accurately gauge the impact of this PR on Besu's performance, particularly regarding block processing, the most effective approach is to deploy it on a dedicated environment with real data. It's preferable to use an environment with many deposits, and then profile the node to observe any impact on performance. In the meantime, I've identified two pertinent methods to assess performance by conducting microbenchmarking with JMH

DepositDecoder.decodeFromLog
BodyValidation.depositRoots

During block processing, both methods are invoked, with DepositDecoder.decodeFromLog being called iteratively within a loop that depends on the quantity of receipts and logs per receipt present in the block
Block processing
AbstractEngineNewPayload.syncResponse
        BodyValidation.depositsRoot
	MergeCoodinator.rememberBlock
		MergeCoodinator.validateBlock
			MainnetBlockValidator.validateAndProcessBlock
				MainnetBlockValidator.validateAndProcessBlock
					MainnetBlockBodyValidator.validateBodyLight
						AllowedDeposits.validateDeposits
							DepositDecoder.decodeFromLog (called several times)
						AllowedDeposits.validateDepositsRoot
							BodyValidation.depositsRoot

Block creation
AbstractBlockCreator.createBlock
	BodyValidation.depositsRoot
	DepositDecoder.decodeFromLog (called several times)

The microbenchmarking of both methods (Keccak256 was added to enable a comparison point)
Benchmark                                     Mode  Cnt       Score      Error  Units
DepositDecoder.decodeFromLogBenchmark         avgt  100   12261.105 ±   80.786  ns/op
DepositDecoder.keccakk256Benchmark            avgt  100     306.937 ±    0.377  ns/op
BodyValidation.depositsRootBenchmark            avgt  100  238915.938 ± 4451.589  ns/op

If I'm not wrong, BodyValidation.depositRoots is called twice during block processing, and it takes 1/4 ms to execute, I think we can save one execution but even with both executions, the overhead is acceptable.
DepositDecoder.decodeFromLog overhead will depends on the number of receipts per block and the number of logs per receipt. If there're for example 1000 logs to process, this represents 13 ms overhead for block processing and block creation.
I started also a node on mainnet with PR to test against main on current fork (previous commit of this PR 795b7c4d), I don't see any performance regression on block processing or FCU

From what I gathered, I don't see a blocker to merge in termes of performance

I've started a regression, fresh X_CHECKPOINT sync of 3 BONSAI nodes: sepolia, goerli, mainnet.

I've started a regression test, fresh X_CHECKPOINT sync of 3 BONSAI nodes: sepolia, goerli, mainnet.

This has passed regression: all nodes got in sync and have stayed in sync. No errors in the logs.

the PKI unit test failures will be fixed by a merge from main

@jframe @siladu I have updated the way the depositContractAddress get passed into the AbstractBlockCreator, not sure if I have changed it correctly so please take a look. Particularly the logic of setting a default address DEFAULT_DEPOSIT_CONTRACT_ADDRESS in the case it is absent while creating block.
Since DepositsValidator.AllowedDeposits.validateDeposits() still needs a depositContractAddress to filter the logs, it still relies on MaineProtocolSpecs to pass in the address when initializing.
To summarize, we need depositContractAddress for two things, one for filtering logs to get deposits to include in block body in createBlock(), and one for filtering logs to validate deposits.
The former has depositContractAddress passed around like this: BesuControllerBuilder -> MergeCoordinator -> MergeBlockCreator with MergeBlockCreator setting the default address if absent
The latter is like this: MainnetProtocolSpecs -> DepositsValidator.AllowedDeposits() -> DepositsValidator.AllowedDeposits.validateDeposits()

Looks like there couple tests failing because MergeBesuControllerBuilder.createTransitionMiningCoordinator() now reads genesis config. I will fix them when you guys are okay with my proposed change change on createBlock().

Reran some regression tests (deposits disabled) on latest changes with a local interop and sepolia sync ✅ Think this is ready to merge if @jframe is happy with latest changes.

Looks fine to me

Thanks @jframe. I will hold off merging until we are sure main branch is clear: there are some issues on main found during the 23.4.2 soak.


.help-block after div.input-append displayed next to the input

div.input-append is a block that contains only floating elements, thus gets a 0px height; if a .help-block follows the div.input-append, it is displayed next to the div.input-append instead of under it, because the 0px-height div.input-append does not offset it vertically. adding "clear: left" to the .help-block seems to correct this problem, but I'm not sure if that won't break something else.

Duplicate: #419 and #415


Seeing an error in the sauce gem

Hello, I am using ruby 2.0.0-p645 and when I run bundle exec rake sauce:spec I see the following:
Note: This happens when I run it in a docker container. Might be related? It otherwise works fine from my Mac running ruby 2.0.0-p247.
  Sauce public job link:
     Failure/Error: Unable to find matching line from backtrace
     NoMethodError:
       undefined method `map' for nil:NilClass
     # /vendor/bundle/ruby/2.0.0/gems/sauce-3.5.6/lib/sauce/config.rb:223:in `caps_for_location'
     # /vendor/bundle/ruby/2.0.0/gems/sauce-3.5.6/lib/sauce/rspec/rspec.rb:126:in `block in included'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/extensions/instance_eval_with_args.rb:16:in `instance_exec'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/extensions/instance_eval_with_args.rb:16:in `instance_eval_with_args'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example.rb:247:in `instance_eval_with_args'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/hooks.rb:93:in `block (2 levels) in run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/hooks.rb:95:in `call'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/hooks.rb:95:in `run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/hooks.rb:424:in `run_hook'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example_group.rb:325:in `run_around_each_hooks'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example.rb:256:in `with_around_each_hooks'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example.rb:111:in `run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example_group.rb:386:in `block in run_examples'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example_group.rb:382:in `map'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example_group.rb:382:in `run_examples'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/example_group.rb:367:in `run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/command_line.rb:28:in `map'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/command_line.rb:28:in `block in run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/reporter.rb:34:in `report'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/command_line.rb:25:in `run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/runner.rb:80:in `run'
     # /vendor/bundle/ruby/2.0.0/gems/rspec-core-2.13.0/lib/rspec/core/runner.rb:17:in `block in autorun'

Anything on this?

I think the gem is choking on RSpec when it's trying to give you a public job link, but it;s weird it's only on containers.
What happens if you run your tests serially?

seeing the same thing... weird thing is it works fine using the RubyMine IDE... cannot get tests to run thru the console


Question: how to configure luacheck to check luacheck?

When I edit a .luacheckrc file, my editor detects that it's lua and lints it. That seems fine, but luacheck doesn't know how to lint a .luacheckrc file and gives warnings.
Could luacheck include a std for its own config file?
For now, I'm using this in my .config/luacheck/.luacheckrc and project .luacheckrc files:
files['.luacheckrc'] = {
    allow_defined_top  = true,
    globals = {
        'files',
    },
    ignore = {
        '131', -- Unused global variable
    },
}

Looks like luacheck does configure itself to check itself, but it wasn't working for me.
Turns out I was always passing --std lua51 to my linter (vim-ale) so luacheck could never fallback to its default std='luacheckrc'. I switched to using a default .luacheckrc file and now my .luacheckrc files are mostly linted correctly.
For any other ale users, all luacheck config now lives in .luacheckrc and my ale config is now simply:
let g:ale_lua_luacheck_options = '--default-config ' .. expand('~/.dotfiles/lua/.luacheckrc')


Change default behavior for the square env

I think this should be loaded from an env var unless otherwise specified or is defined as a user. This allows automation when pushing to ci tooling.

#4 # #


Add type information for needed attributes.

Description

We can currently query which attribute names and scopes are requested in a shader. This PR extends that idea to also allow querying the attribute types. This now more closely matches the equivalent available queries for user data.
For example, this shader:
shader Shader
{
  color c;
  getattribute("user_color", c);

  string s;
  getattribute("user_string", s);
}

allows us to do this:
int nattr = 0;
if (shadingSys->getattribute(shaderRef.get(), "num_attributes_needed", nattr) && nattr)
{
  // this already works
  OIIO::ustring* names = nullptr;
  shadingSys->getattribute(shaderRef.get(), "attributes_needed", OSL::TypeDesc::PTR, &names);

  // this is the added feature
  OIIO::TypeDesc* types = nullptr;
  shadingSys->getattribute(shaderRef.get(), "attribute_types", OSL::TypeDesc::PTR, &types);

  // nattr: 2
  // names: ["user_color", "user_string"]
  // types: [OIIO::TypeColor, OIIO::TypeString]
}

The motivation behind this feature is to perform additional type validation at material compile time when determining what primvars can be provided to the shader.
One side-effect of this change to be aware of is that, as mentioned in the code comments, if the same name is requested multiple times with different types, it will now be reported multiple times. Hopefully this is not too much of an issue as the same behaviour also occurs when an attribute is requested in multiple scopes, or when user data is requested with multiple types.
Tests

I wasn't able to find any existing unit tests for the "attributes_needed" feature to use as a starting point, if they do already exist please let me know and I can make those changes. I did see a spot in testshade where it seemed appropriate to add a usage of this feature.
Checklist:

[x] I have read the contribution guidelines.
[x] I have previously submitted a Contributor License Agreement.
[x] I have updated the documentation, if applicable.
[x] I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
[x] My code follows the prevailing code style of this project.

Looks like there are a few formatting issues to fix (look at the logs of the failed clang-format test), and also needs a DCO message attached to the commit. But the code LGTM.

@curtisblack Ping! -- can you please push an update with the DCO and fixed formatting so I can merge this in time for the monthly patch release this week?


Replace pipes.quote with shlex.quote on Python 3

The shlex.quote() API is available from Python 3.3 on; pipes.quote() was never documented, and is removed in Python 3.13.
Fixes #119.

When https://github.com/xolox/python-humanfriendly/pull/75 is also applied, all tests pass on Python 3.13.


[Bug]: Can't Create Post Threads

Summary
Using the replyTo parameter in createPostRecord with the URL of a previous post results in an error.
Reproduction Steps
I am writing an app that fires Post objects. When the number of objects is greater than one, I store the StrongReference of the previous post, so I can use the recordURI result as the value in the replyTo property for the subsequent post.
I found these calls were resulting in errors, complaining about malformed URIs.
Expected Results
I was hoping the reply post in the thread would successfully publish.
Actual Results
I got the error stated above.
What operating systems did you experience this bug? (We'll count Docker as an operating system.)
macOS, Other
Operating System Version
On Xcode 16 beta 6 in a simulator running iOS 18.
ATProtoKit Version
Current main 0.17.5
Additional Context
No response

Interesting. I saw that you've made a PR as well. I'll be releasing a newer version of ATProtoKit before the week is over. Once that's done, I would suggest that you look at your PR and update things. From a quick skim through your code, some of the things that you've fixed are actually in my update, hence why I'm making this suggestion.
Thanks for submitting this. I'll have to test out your code to make sure things are working correctly after you update it with my changes.

Thank you. Please let me know when you do that and I'll update! 🙌

@MasterJ93 Do you have an update on this?

Sorry for the late reply.
There's a bug with respect to uploading the videos and I'm trying to get this resolved. I've been spending all day and night yesterday to figure it out. Once I have that fixed, I'll release the update.

Sorry for the extremely long delay: I didn't think it would take this long to get uploading videos to work. But version 0.18.1 is now out.
Please look at your pull request and update it in order to prevent any conflicts.

@MasterJ93 Just pushed to resolve the conflict, thank you!

I've merged the relevant pull request and it's now released in the latest hotfix, so I'm going to close this issue. If the issue is still happening, please feel free to create a new issue or re-open this. Thanks for your bug fix!


Http driver repository has to be deleted

Http driver repository has to be deleted, namely:
http://maven.nuiton.org/nexus/content/groups/releases/

Fixed

virified


How to invoke code before RTIC main part.

Hello,
while developing firmware code using RTIC we got to the need to invoke STM32 system firmware to support our firmware update. Jumping to STM32 F4(12) system firmware (also boot) form the application code is pretty simple:
fn main() -> ! {
    let SYSBOOT_ADDR : u32 = 0x1FFF0000;
    let vt = SYSBOOT_ADDR as *const u32;

    unsafe {
        (*STK::ptr()).ctrl.modify(|_, w| w.bits(0x0));
        (*STK::ptr()).load.modify(|_, w| w.bits(0x0));
        (*STK::ptr()).val.modify(|_, w| w.bits(0x0));

        // sysflash remap to 0x0 addr
        (*SYSCFG::ptr()).memrm.modify(|_, w| w.mem_mode().bits(0x1));

        let mut periph = cortex_m::peripheral::Peripherals::steal();
        periph.SCB.vtor.write(vt as u32);
        periph.SCB.invalidate_icache();
        cortex_m::asm::bootload(vt);
    }
    loop {
    }
}

however the process is complicated when there was some hardware already initialized and set. This needs to be reset into its default state. This itself is quite hard to do and so far impossible for me to the with RTIC application. What may simplify things is if there would be some way how to invoke application code even before main RTIC code. Some kind of main_start_interceptor function or so. There user may put his/her bare-metal rust code to do init business (or jump to system firmware) once the conditions are met (like for example button is hold down during the startup).
Obviously: the issue is that main is machine generated into the rtic-extension.rs and it's a bit harder to modify correctly....

Hi!
Did you try [pre-init]?
https://rtic.rs/2/book/en/by-example/app_init.html?highlight=pre-init#app-initialization-and-the-init-task
which in turn links to https://docs.rs/cortex-m-rt/latest/cortex_m_rt/attr.pre_init.html
Another approach, if always going through a bootloader, by doing an actual reset to ensure you get all peripherals into a known state.
After the reset, depending on some leftover state/GPIO state as already mentioned maybe then jump into the system firmware updater application instead of the regular application.
Many ways to go about it, but on the direct question "how to invoke code before RTIC main part" I would reply [pre-init] :)
I will close the issue, but feel free to reopen/discuss further!


Can we apply the collapsible animation to our own react native flatlist ?

can we have any hooks to used to animate  the  header when  react native flatlist is used ?

The library does wrap a normal RN FlatList and attaches some custom hooks, take a look at: https://github.com/PedroBern/react-native-collapsible-tab-view/blob/main/src/FlatList.tsx
What is your use case?

yes, i noticed . my issue got solved
thank you 👍


Tiny tiny details

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time.
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with npm run test and lint the project with npm run lint and npm run prettier

Reach for the Summit intensifies


Update whatsnew.md

I believe there is a mistake in the "What's New in EF Core 9" docs.
In the "Force or prevent query parameterization" there is an information that EF Core 8.0.2 introduces an EF.Constant method.
I guess it should be EF Core 9.0.2.
If it's not a mistake, please abandon the PR.

Ok, I can see that's not a mistake, sorry about conduction. I am closing the PR.


Certain scaffolding blocks not being used by mineflayer

when i add any type of wool or leaves, my mineflayer bot doesn't ever use the blocks.
movements.scafoldingBlocks = [     mcData.blocksByName.white_wool.id,     mcData.blocksByName.orange_wool.id,     mcData.blocksByName.dark_oak_leaves.id, ]
when i add block ids for stone and dirt they work though.

Yes that's a mistake in the examples and code that i need to fix. ScafoldingBlocks expect item id and not block id. So it works for some ids that are the same for the item and block but most don't work.
The correct way to define that is: movements.scafoldingBlocks = [ mcData.itemsByName.white_wool.id, mcData.itemsByName.orange_wool.id, mcData.itemsByName.dark_oak_leaves.id]

If all else fails, you can also simply get the block's number IDs from here, but what Karang said will probably work too.


add support macOS 13.0 Beta

RealtekCardReaderFriend_1.0.2__RELEASE.zip

@0xFireWolf if you want I update the readme and create new vers kext release and debug with updated sdk.

I have released the new artifacts. Thank you.


Linux aarch64

What about Raspberry Pi? Does KMP/Native support it? If so: how should the naming of executables be done? Shall we keep doing what Fiji/ImageJ2 has done until now, which is to append an os/arch suffix? jaunch-linux-x64, jaunch-linux-aarch64, jaunch-macos, jaunch-windows-x64.exe? And then for portable applications, symlink or copy to the current os/arch? There's no reason to do that for the configurator though, only for the native launcher executable. The native launcher should always reach out to a jaunch executable with matching os/arch.

KMP/Native totally supports aarch64 Linux. And as of 12aeba53498d296f969288e564f3a68b07306f87, so does Jaunch! :raised_hands:


How to create a tensorflow lite plugin for Unity

I'm trying to use tensorflow lite in unity.
I need plugins to run my project.
Especially a plugin for IOS [tensorflowlite_c]
Thank you!

@Deepak-HpyAda ,
Please provide details about what platform you are using (operating system, architecture). Also include your TensorFlow version. Also, did you compile from source or install a binary?
Make sure you also include the exact command if possible to produce the output included in your test case. If you are unclear what to include see the issue template displayed in the Github new issue template.
We ask for this in the issue submission template, because it is really difficult to help without that information.

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!

Hi. Any updates on this? Thx

Hi. Is it possible to build the tensorflowlite_c.a static library for use in iOS? The readme only listed the bazel command for Android and linux but not for iOS.

Hi, a simple way is importing pre-build TensorFlowLiteC.framework from CocoaPods
Just make the blank Xcode project with Podfile and copy it.
pod 'TensorFlowLiteObjC', '0.0.1-nightly'

and need to modify [DllImport (TensorFlowLibrary)] to  [DllImport (__Internal)]
of use my PR #34450


Internal error occurred: failed calling webhook. Suddenly for existing cert-manager deployment

We configured a Kubernetes cluster in Jan, including cert-manager, on the Linode offered Kubernetes.
Describe the bug:
Everything worked fine, until about 2 weeks ago when our FluxCD suddenly started reporting errors related to cert-manager webhook. The same error occurs when using kubectl apply for a Certificate resource.
basvodde@MacBook-Pro-7 cluster-party % kubectl apply -f certificate-party.yaml
Warning: resource certificates/partydomain-cert is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
Error from server (InternalError): error when applying patch:
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"cert-manager.io/v1\",\"kind\":\"Certificate\",\"metadata\":{\"annotations\":{},\"name\":\"partydomain-cert\",\"namespace\":\"public-sites\"},\"spec\":{\"dnsNames\":[\"party.domain.com\"],\"issuerRef\":{\"kind\":\"ClusterIssuer\",\"name\":\"letsencrypt\"},\"secretName\":\"partydomain-cert\"}}\n"}}}
to:
Resource: "cert-manager.io/v1, Resource=certificates", GroupVersionKind: "cert-manager.io/v1, Kind=Certificate"
Name: "partydomain-cert", Namespace: "public-sites"
for: "certificate-party.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded

As far as I know, there was no change happening at the cluster at this point in time. We did notice that the cert-manager pod had restarted and that might be related to this.
I have tried to login on another pod and connect to the webhook service using wget. This fails unless I turn off the wget https certificate validation.
basvodde@MacBook-Pro-7 cluster-party % kubectl exec image-reflector-controller-xx-xx -n flux-system -ti -- wget https://cert-manager-webhook.cert-manager.svc:443/mutate
Connecting to cert-manager-webhook.cert-manager.svc:443 (<IP_ADDRESS>:443)
140378084571976:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1919:
ssl_client: SSL_connect
wget: error getting response: Connection reset by peer
command terminated with exit code 1

And turning off certificate validation:
basvodde@MacBook-Pro-7 cluster-party % kubectl exec image-reflector-controller-xx-xx -n flux-system -ti -- wget https://cert-manager-webhook.cert-manager.svc:443/mutate --no-check-certificate
Connecting to cert-manager-webhook.cert-manager.svc:443 (<IP_ADDRESS>:443)
wget: server returned error: HTTP/1.1 400 Bad Request
command terminated with exit code 1

As far as I can see, all the pods are healthy and running. Nothing stood out in the pod logs.
Let me know what additional information I could provide or what I could check.
Expected behaviour:
I'd expect the kubectl to work like before.
Steps to reproduce the bug:
It suddenly started to happen on our cluster. I did avoided restarting pods or any random recovery action until I understand what the problem is.
Anything else we need to know?:
Environment details::

Kubernetes version: v1.25.6
Cloud-provider/provisioner: Linode
cert-manager version:  v1.11.0
Install method: Helm

/kind bug

Ok. This issue just got stranger for me.
Just as it suddenly started about 2 weeks ago, it now also suddenly stopped and started working again as it did before.
Since I cannot reproduce this now and everything is working again, I suggest closing this issue. I'll leave it open a little for if others encounter it and will ask Linode whether they happened to have an idea why/how this could have happened. If I do hear back then I'll add that info to the issue still.


WIP: Add backdrop modal widget

I'm not sure that's right given the presence of position: fixed
On Mon, 3 Jun 2019 at 11:21, Elliot Cameron<EMAIL_ADDRESS>wrote:

@3noch commented on this pull request.
In frontend/Rhyolite/Frontend/Widget.hs
https://github.com/obsidiansystems/rhyolite/pull/64#discussion_r289899652
:

@@ -78,3 +82,25 @@ extensibleListWidgetWithSize n x0 xs0 addAtEnd itemWidget = do
valuesMapD = joinDynThroughMap $ fmap (fmap snd) $ resultMapD
valuesD = fmap Map.elems valuesMapD
return valuesD

+-- | Widget used as a modal div for widgets that want to take some action when clicked anywhere but itself, such as dropdown widgets or the like.

-- The first argument is a CSS class name, the suggested CSS class styling for use of this widget is as follows:
-- position: fixed;
-- top: 0;
-- bottom: 0;
-- right: 0;
-- left: 0;
-- z-index: 100;

z-index only works for explicitly positioned elements. So the code here
works but must be placed before all other DOM-building. As such it is far
less convenient to use. Here's an example of the same idea, but where we
introduce a monad to make it much more ergonomic (you can use tellModal
from anywhere in the app and it will build the DOM at the bottom to give it
natural stacking order on top of everything else).
https://gitlab.com/obsidian.systems/tezos-bake-monitor/blob/develop/tezos-bake-central/frontend/src/Frontend/Modal/Base.hs#L106-108
Also note in this example, we pass the close Event into the modal-building
function so that it can choose to accept background clicks or not accept
them as close events. It also accepts Esc key.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/obsidiansystems/rhyolite/pull/64?email_source=notifications&email_token=ABYWSRS6M542W2EERB4HAMTPYUZHNA5CNFSM4HRJTAF2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB2M2KRQ#pullrequestreview-244950342,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYWSRRDZXCYS5HQCRDTST3PYUZHNANCNFSM4HRJTAFQ
.

@hSloan What's going on with this PR? It's been in WIP status for quite some time.

I will upstream our modal code as a PR to provide an alternative to this.

See #81

#81 was merged.


export let test = await foo(); throws ReferenceError when imported

Summary
Importing this module throws a ReferenceError ('foo' is not defined) instead of working:
function foo() {
	return {a: "b"};
}

export let test = await foo();

Operating system
Linux
Steps to reproduce

Create these files in a folder and load index.html:

index.html:
<script src="./scriptA.mjs" type="module"></script>

scriptA.mjs:
import {test} from "./scriptB.mjs";

scriptB.mjs:
function foo() {
	return {a: "b"};
}
export let test = await foo();

ladybird logs [ReferenceError] 'foo' is not defined.

Expected behavior
The module should be imported successfully and test should be filled with the return value of foo(), async or not.
Actual behavior
ReferenceError.
URL for a reduced test case
Not a reduced test case, but it does happen here, on page load, and makes the entire site unusable.
https://battle.crossuniverse.net/intro/index.html
HTML/SVG/etc. source for a reduced test case
Already given above.

Log output and (if possible) backtrace
See screenshot below.
(clipboard sharing to my Linux VM doesn't work -_-)

Screenshots or screen recordings

Build flags or config settings
none(?)
Contribute a patch?

[ ] I’ll contribute a patch for this myself.

I've looked into this some more, this seems to be due to the fact that modules with top-level-await aren't properly supported yet.
SourceTextModule.cpp just wraps all the module's code in an async function and runs tht instead of using AsyncBlockStart directly.
(and making it do that just breaks things even further, so I've decided that this is beyond me and I won't do it as my first PR)


Possible Memory Leak

I have suffer from memory leak when running MultiStickSSDwithRealSense_OpenVINO_NCS2.py with a single stick and USB Webcam.
The memory leak occurs on Laptop and Odroid XU4 with rate about 200MB/minutes.
I can run SingleStickSSDwithUSBCamera_OpenVINO_NCS2.py normally without any memory leak, my guess is the problem is at the multiprocessing where the already processed image didn't removed from the memory.
Laptop Specification:
Ubuntu 18.04.1 (x64)
i7-4710HQ (2.5 GHz / 4 Cores)
GTX 850M (2 GB VRAM)
8 GB RAM
ODROID XU4 Specification:
Ubuntu Mate 16.04 (ARM)
Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 (2 GHz / 8 Cores)
Mali-T628 MP6
2 GB RAM
Camera:
Laptop Webcam, Logitech C270, PS3 EYE

@agtbaskara
I tried it.

My Environment
USB Camera
NCS2
Corei7 + Ubuntu16.04

Test command

$ python3 MultiStickSSDwithRealSense_OpenVINO_NCS2.py -wd 1280 -ht 720 -mod 1

or

$ python3 MultiStickSSDwithUSBCamera_OpenVINO_NCS2.py -wd 1280 -ht 720 -cn 1

Results
320x240 --> Measured for 5 minutes, no memory leak
640x480 --> Measured for 5 minutes, no memory leak
1280x720,720p --> Measured for 15 minutes, no memory leak

Could you tell me what kind of operation you did?

Sorry to be out of topic but are you running an NCS 2 on a odroid XU4 ? I thought it was only compatible with raspberry pi beside intel proc.

@blitzvb
@agtbaskara
Perhaps it works with any CPU that supports the armhf (ARMv7) architecture.
$ sudo dpkg --add-architecture armhf
$ sudo apt-get update
$ sudo apt-get install libusb-1.0-0:armhf libudev1:armhf libstdc++6:armhf

The cause of the memory leak may be caused by the difference in OpenVINO version.

Hi, @PINTO0309  thanks for your code.
I also notice memory leak on my raspberry pi 3 about 200 kb/s when running MultiStickSSDwithUSBCamera_OpenVINO_NCS2.py  :

Raspberry pi 3 details:
OS: Raspbian Stretch
CPU: ARMv7

But when I run the same code on my PC, it works without memory leak.

PC details:
OS: Ubuntu 16.04
CPU: x86 64

It seems to be related to queue operation  when camera frames are put into frameBuffer.  I did the following experiments:

Running camera process without inference process, the memory leak still occurs.
Running camera process without inference  process, and comment  queue operation, memory leak disappears

@onion233
Thank you very much for your cooperation in the survey.
I will start thinking about how to fix this tonight.
It is very strange that the situation will change depending on the CPU/OS difference.

Memory leak investigation.
RaspberryPi3 + USBCamera + NCS2
MultiStickSSDwithUSBCamera_OpenVINO_NCS2.py
Real-time monitoring command
$ watch -n 1 "cat /proc/meminfo | egrep -e 'Active:|Inactive:|MemFree:'"

$ python3 MultiStickSSDwithUSBCamera_OpenVINO_NCS2.py

5 minutes monitoring
https://youtu.be/9bAVfGUzmrU
1 minutes GIF

I observed it for 5 minutes, but as a result, the memory usage did not exceed 300 MB.
Unnecessary areas appear to be collected in real time.
I have no idea what is different between you and my environment... :sob:

@PINTO0309  Thanks for your investigation! Could you provide your python version and opencv-python version?

@onion233
Yes. of course.
Python 3.5.3
OpenCV 4.0.1-openvino

@PINTO0309 @agtbaskara
Hi, guys. I refreshed my raspberry pi and followed the configuration steps again. This time I do not suffer from the memory leak over 30 minutes.
python3 MultiStickSSDwithUSBCamera_OpenVINO_NCS2.py -cn 0 -numncs 1
It's weird that my configuration stays the same but the code behaviors differently. The most likely reason for the leak is the old frame in frameBuffer was not really freed due to "some environment issue"

@agtbaskara
Thank you for contributing to problem solving!
I care what the essential problem was.