Add raytrilium extension

Description
Adds an extension that creates notes in Trilium from Raycast. Makes use of Trilum's ETAPI and requires the user generate an API key and put it into the Raycast configuration.
Screencast

Checklist

[X] I read the extension guidelines
[X] I read the documentation about publishing
[X] I ran npm run build and tested this distribution build in Raycast
[X] I checked that files in the assets folder are used by the extension itself
[] I checked that assets used by the README are placed outside of the metadata folder

Is this ready for another review?

@pernielsentikaer Yes, although the API seems to work for me locally with or without a correct token so I am poking into what's going on there.

Converting to a draft for now, just ping me then 🙂


Add pytorch lightning support.

Initial support for pytorch lightning, to enable multi GPU training.
Outsourced the model for the notebook into it's own folder, we should think about how we can support the notebooks without keeping two files in sync.

Looks great!
We can use nbdev to be able to export the model from a notebook to normal .py files. I use it already for the token extraction scripts (which I needed to run from the command line using GNU parallel)


Add Survey Switcher/Quantity

Changes

Added a switcher to allow moving between different surveys, in order to ease having to lookup test data
Added a quantity to allow surveys to be submitted multiple times

How to test

Use as part of a compose setup and check surveys can be navigated between on main index page
Increment the number of submissions and check it is transformed the desired number of times

Who can test

Anyone but @iwootten

New features present. Merged.


why module federation load url wrong

Bug report

What is the current behavior?
app A load from app B which is expose some component use module federation case wrong url.
If the current behavior is a bug, please provide the steps to reproduce.

app B expose somethings

app A use it

app A load remoteEntry.js

app A load component from remoteEntry.js but it domain comes from app A, the correct domain is from app B

it must be localhost:1000, that was my app A server domain.

What is the expected behavior?
do the right things,thanks.

Other relevant information:
webpack version:  5.72.0
Node.js version:  16.13.1
Operating System:  win 10
Additional tools: nextjs for server-side render

https://github.com/module-federation/module-federation-examples/tree/master/nextjs-react when i follow nextjs-example，it present same result.

maybe you should specify publicPath ?

publicPath

I have the same problem, did you find a solution ？

https://github.com/module-federation/module-federation-examples/tree/master/nextjs-react when i follow nextjs-example，it present same result.
@CHANCCCZQ I have the same problem, did you find a solution ？

maybe you should specify publicPath ?

How to specify publicPath? The publicPath is '/' in my host and remote project.

@lifeilu Why you need /? Can you remove public path everywhere?


HIVE-27899: Killed speculative execution task attempt should not comm…

What changes were proposed in this pull request?
Try canCommit after process.
Why are the changes needed?
We should avoid speculative tasks being committed at the same time. Detailed information see: https://issues.apache.org/jira/browse/HIVE-27899
Does this PR introduce any user-facing change?
No
Is the change a dependency upgrade?
No
How was this patch tested?
test on our cluster

@abstractdog Can you please review this PR? It is reasonable to use AM’s synchronization mechanism for commit file.

@deniskuzZ Hi, can you please review the HIVE-27985?

@deniskuzZ @ayushtkn @abstractdog @glapark
Here we have the following problem about repetition in our production problem:

(1) When speculative execution is enabled, I found that the cluster occasionally has file duplication problem.

When speculative execution is turned on, the slower task attempt will be killed. I found that the killed task may commit unfinished files. So I submit HIVE-25561 to solve this problem.

(2) When I apply HIVE-25561, I found that duplicated file still happened, but the probability was very very low.

I found that the duplication of files was caused by two different attempts of the same task being committed at the same time. So I submit HIVE-27899 to solve this problem.

(3) After the task attempt is committed and before the appMaster receives the task success message, if an exception occurs, file duplication may occur.  See for  information in HIVE-27985.

We can use task-based but not attempt-based file names. Even if there are duplicate files, since the names are the same, the file committed later will delete the file committed earlier. And because HIVE-25561 is applied, we can make sure that all commit file is generated by successfull task attempt . So I submit HIVE-27986.


Cannot clear custom errors when returned by the server

Hello, thanks for the library!
Got a small issue
When i'm returning a custom error from the action as following:
export async function action({request, context, params}: ActionArgs) {

    const {
        data,
        errors,
        receivedValues ,
      } = await getValidatedFormData(request, zodResolver(createSpaceInput))

      try {
        const result = context.api.onboarding.setUpSpace.mutate({
            name: data.name
          })

        return json({ space: result })
      } catch(e) {
        return json({
            errors: {
                root: {
                    message: e.message
                }
            }
        })
      }
  }

The error can be displayed just fine.
However, when i try to clear the error for example onChange it simply doesn't clear.
 const form = useRemixForm({
    mode: "onSubmit",
    defaultValues: {
      name: "",
    },
    resolver: zodResolver(formSchema),
  });

<RemixForm onSubmit={form.handleSubmit} method={"POST"} onChange={() => {
              console.log('form on change', form.formState.errors)
              form.clearErrors('root')

            }}>

I have also noticed that when I return an error which has the same name as one of the fields:
export async function action({request, context, params}: ActionArgs) {
     ... // rest of the function

        return json({
            errors: {
                name: {
                    message: 'some backend error coming from external api'
                }
            }
        })
  }

It behaves the same way, as in the message is shown just fine, but it can't be cleared up
Any tips?

@fenos Hello! The issue you're facing is the fact that when you return the remix errors from the backend they are consumed internally by the hook until they are cleared in the useActionData (eg you submit again). This means that there is no way to remove the errors via form.clearErrors, but this should not indeed be the case but should be cleared. I will make a patch for this when I get the time and this behavior should remove it so this is definitely not the way it should work. Until then I could recommend that you check if the error that comes from the hook is the same as the be one and clear it like that by using useActionData and handling the errors that way

Any progress on this? I have just come across the same issue. If you have a recommend solution I can implement it for you.

Any progress on this? I have just come across the same issue. If you have a recommend solution I can implement it for you.

@Centerworx i think the solution is to have a simple setState that is set to true on submit and false on reset and depending on that it consumes the be errors

@AlemTuzlak Working on it. There is an issue around useActionData return the value before submit true is set.  Even though it is set  to true before calling submit handler. But this may just be test implementation issue.

@AlemTuzlak I have the fix done and tested. I'm having an issue pushing it. Problem with my git.

Hi, first of all, thanks to @AlemTuzlak for making remix-hook-form. I used usePrevious in the project to get the difference of serverErrors and then merged it, which temporarily solved the problem.
  const serverErrors = data?.errors || emptyErrors
  const previousServerErrors = usePrevious(serverErrors)

  const deletedErrorKeys = React.useMemo(() => {
    const keys = Object.keys(serverErrors)
    const prevKeys = previousServerErrors ? Object.keys(previousServerErrors) : []

    return prevKeys.filter((key) => !keys.includes(key))
  }, [previousServerErrors, serverErrors])

  const formErrors = React.useMemo(() => {
    const localErrors = methods.formState.errors as FieldErrors<Output>

    const mergedErrors = mergeErrors<Output>(localErrors, serverErrors, validKeys)

    for (const key of deletedErrorKeys) {
      delete mergedErrors[key]
    }

    return mergedErrors
  }, [methods.formState.errors, deletedErrorKeys, serverErrors, validKeys])

Is there any progress on this? I just run into the same issue.

So this might be potentially fixed with the fact that I moved to using the react-hook-form native "errors" prop, can anyone confirm?


feat(sandbox): commit

Test Steps

[ ] go to http://localhost:4200/#/components/breadcrumbs
Click on the

It should open the respective stackblitz with the stub demo code (it's should not be working, this is just so we make sure we are on the same page for what the demo file structure should look like and provide a running example to communicate around)

General Tests for Every PR

[ ] npm run serve:prod still works.
[ ] npm run tslint passes.
[ ] npm run stylelint passes.
[ ] npm test passes and code coverage is not lower.
[ ] npm run build:lib still works.

Screenshots or link to StackBlitz/Plunker

Meant to open up against my own fork. Closing.


College Detailed page

Description
Please include a summary of the change and which issue is fixed. List any dependencies that are required for this change.
[Feat] : Redesign college detailed page #860
Fixes #860(issue_no)
Replace issue_no with the issue number which is fixed in this PR
Screenshots

Checklist

[x] Tests have been added or updated to cover the changes
[x] Documentation has been updated to reflect the changes
[x] Code follows the established coding style guidelines
[x] All tests are passing

@thestarsahil
i fetched upstream and make fresh pr
kindly check this and merge it

Same issue with job page

@thestarsahil
i resolve theme issue
please check this and merge it

Still not working

ok i reclone whole repo and make another pr


Fix the duplicated "dummy_method_to_enforce_bundling" in C header within multi-blocks

This PR fixes https://github.com/fzyzcjy/flutter_rust_bridge/issues/1014. And I think the idea @WangJiaJun8922 proposed is correct (thanks~), since dummy_method_to_enforce_bundling has nothing to do with the shared stuff in the context of multi-blocks. In any case, giving dummy_method_to_enforce_bundling a suffix of API block/class name makes sense, unless --class-name is not specified.
In addition, the bail function is refined to make log output consistent.

I realized that for Mac/Ios, the name for presetting dummy_method_to_enforce_bundling should be changed, too.

I realized that for Mac/Ios, the name for presetting dummy_method_to_enforce_bundling should be changed, too.

Why? would be great to know more details

By the way, where does FlutterRustBridgeExample come from for example with_flutter?

Which FlutterRustBridgeExample - may need to point out the exact line of code

Why? would be great to know more details

Referring to the CI issuefrom macOS, the signature is still dummy_method_to_enforce_bundling, but not  dummy_method_to_enforce_bundling_FlutterRustBridgeExample. Maybe the swift file need to be changed before generation.

Which FlutterRustBridgeExample - may need to point out the exact line of code
In example with_flutter,  let c_dummy_code = generator::c::generate_dummy(&effective_func_names, &config.class_name); , the config.class_name is FlutterRustBridgeExample, but I didn't find where the specific name is pushed in for this example(I checked CI test yaml, justfile, build.rs).

Hmm, so is it possible to generate one extra function, dummy_method_to_enforce_bundling, which calls the (possibly multiple) dummy_method_to_enforce_bundling_*?
For example, I see you generate two functions:

Can we generate one more:
static int64_t dummy_method_to_enforce_bundling(void) {
      int64_t dummy_var = 0;
    dummy_var ^= dummy_method_to_enforce_bundling_apiclass1();
    dummy_var ^= dummy_method_to_enforce_bundling_apiclass2();
    return dummyvar

etc.
This function should only be generated once (say, in the first file), but should call all dummy_method_to_enforce_bundling_*

By doing so, we avoid doing breaking changes :)

Within https://github.com/fzyzcjy/flutter_rust_bridge/pull/1024/commits/a9b56702e26d3f829e10550238c2fcc5508496ae,  there are 3 things needed to mention:

the signature for frb_codegen is refined to include the whole configs, which is essential for catching global information when generating for a specific config. Also, this modification paves the way for future refinement of the shared stuff.
replace crate extend with trait mechanism, since it can't be used if it is defined in another module.
For test purpose, add/refine the output of c-header for both "pure_dart" and "pure_dart_multi".

@fzyzcjy, running "just precommit" on my win10 machine with flutter 3.7.1.  The pubspec.lock would output dart: ">=2.18.0 <3.0.0, But CI would output >=2.18.0 <4.0.0. Is there something need to change?

The pubspec.lock would output dart: ">=2.18.0 <3.0.0, But CI would output >=2.18.0 <4.0.0. Is there something need to change?

Hmm maybe check the flutter and dart versoin in the CI? I am not sure why that happens

I did so at first, but then there are inconsistent format issues with dart format. By the way, is it ok to use the latest flutter/dart in CI? I saw flutter 3.7 appear in the previous pr.

I did so at first, but then there are inconsistent format issues with dart format

Hmm...

is it ok to use the latest flutter/dart in CI?

IMHO yes. What is your opinion?

IMHO yes. What is your opinion?
At present, what about making the flutter version of CI to be 3.7.1.

Sure!

CI is fixed in another PR so by merging the master maybe we are ready to go :)

The format issue still exists for ubuntu. Maybe I need to do just precommit in a Linux system.  Anyway, @fzyzcjy, could you please check if the  rust logic is ok?

Sure, I will probably review it within a day!

/cc @temeddix who fixed the CI (https://github.com/fzyzcjy/flutter_rust_bridge/pull/1039)

Right now just precommit is a bit broken. Post-PR https://github.com/fzyzcjy/flutter_rust_bridge/pull/1051 is waiting to be merged, as this allows just precommit to work again.

waiting to be merged

Done ;) (given it is green)

@temeddix， thanks for your fixed CI issue. But here is one thing to mention this format issue. on win10, with flutter 3.7.3:
This line in with_flutter during just precommit would first format into:
external dynamic /* void */ wire_off_topic_memory_test_output_zero_copy_buffer(NativePortType port_, int len);

Then, in afterward task, it would be reformatted back to
external dynamic /* List<dynamic> */
      wire_handle_zero_copy_vec_of_primitive_sync(int n);

I am also reproducing this problem. I will fix it in https://github.com/fzyzcjy/flutter_rust_bridge/issues/1053 - just wait until I fix and update master :)

Good :) I will be busy for a while..

@temeddix take your time :)

I don't understand the issue from CI.

I don't understand the issue from CI.

Well you may debug it (locally?), try to retry running it to see whether it disappears, or revert relavent changes if non critical

I don't understand the issue from CI.

Well you may debug it (locally?), try to retry running it to see whether it disappears, or revert relavent changes if non critical

I  can't debug it locally, because I don't have an APPLE machine. And unfortunately, the issue still occurs.

Hmm which code causes this, and shall we revert it?

Hmm which code causes this, and shall we revert it?
A side question, there is not CI test for pure_dart_multi any longer. Are they deleted on purpose?

There should definitely be tests about that! It may be dropped accidentically when I was refactoring https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/justfile. Feel free to fix it (e.g. in another PR)

There should definitely be tests about that! It may be dropped accidentically when I was refactoring https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/justfile. Feel free to fix it (e.g. in another PR)

I mean the the example in CI test file. Meanwhile, I am out of time these 2~3 days.

Take your time!

I mean the the example in CI test file

Could you please point to that line? Not very sure what is example in CI. The (new) CI file indeed executes the justfile

justfile

Take your time!

I mean the the example in CI test file

Could you please point to that line? Not very sure what is example in CI. The (new) CI file indeed executes the justfile

I mean that I only see pure_dart  example in the CI folder,but not pure_dart_multi:

In addition, I also can't find some command that executes the justifle, could you point that out?

Oh the ci folder calls: https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/justfile

justfile

which line? I didn't find it.

https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/justfile
many places e.g.

https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/justfile
many places e.g.

No, I mean which line of which file in the CI folder calls the justfile?

Each just sometihng in ci.yaml will call the something in /justfile file.

@fzyzcjy, when running  just dart_linter_pana in win10, I got issue:
$     just dart_linter_pana
flutter pub global activate pana
Package pana is currently active at version 0.21.26.
Resolving dependencies...
The package pana is already activated at newest available version.
To recompile executables, first run `flutter pub global deactivate pana`.
Installed executable pana.
Activated pana 0.21.26.
cd frb_dart && pana.bat --no-warning --line-length 80 --exit-code-threshold 0
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics --version`...
INFO       Running `flutter.bat --suppress-analytics --no-version-check --version --machine`...
INFO       Running `git rev-parse --show-toplevel`...
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics pub get --no-example`...
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics pub outdated --json --up-to-date --no-dev-dependencies --no-dependency-overrides`...
INFO       Analyzing package...
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics analyze --format machine bin`...
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics analyze --format machine lib`...
INFO       Running `git init`...
INFO       Running `git remote add origin https://github.com/fzyzcjy/flutter_rust_bridge`...
INFO       Running `git remote show origin`...
INFO       Running `git fetch --depth 1 --no-recurse-submodules origin master`...
INFO       Running `git ls-tree -r --name-only --full-tree origin/master`...
INFO       Unable to parse `pubspec.yaml` from git repository. Invalid argument(s): Path "frb_dart/pubspec.yaml" is not normalized.
           Invalid argument(s): Path "frb_dart/pubspec.yaml" is not normalized.
           #0      GitLocalRepository._assertPathFormat (package:pana/src/repository/git_local_repository.dart:223:7)
           #1      GitLocalRepository.showStringContent (package:pana/src/repository/git_local_repository.dart:156:5)
           #2      checkRepository.matchRepoPubspecYaml (package:pana/src/repository/check_repository.dart:91:36)
           #3      checkRepository (package:pana/src/repository/check_repository.dart:159:27)
           <asynchronous suspension>
           #4      SharedAnalysisContext.verifyRepository (package:pana/src/package_context.dart:72:24)
           <asynchronous suspension>
           #5      checkPubspecUrls (package:pana/src/references/pubspec_urls.dart:60:30)
           <asynchronous suspension>
           #6      followsTemplate.checkPubspec (package:pana/src/report/template.dart:186:25)
           <asynchronous suspension>
           #7      followsTemplate (package:pana/src/report/template.dart:254:26)
           <asynchronous suspension>
           #8      createReport (package:pana/src/report/create_report.dart:42:5)
           <asynchronous suspension>
           #9      PackageAnalyzer._inspect (package:pana/src/package_analyzer.dart:315:15)
           <asynchronous suspension>
           #10     PackageAnalyzer.inspectDir.<anonymous closure> (package:pana/src/package_analyzer.dart:143:14)
           <asynchronous suspension>
           #11     withTempDir (package:pana/src/utils.dart:236:12)
           <asynchronous suspension>
           #12     main (file:///C:/Users/dbsx/AppData/Local/Pub/Cache/hosted/pub.dev/pana-0.21.26/bin/pana.dart:176:19)
           <asynchronous suspension>
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics format --output=none --set-exit-if-changed --line-length 80 C:\Users\dbsx\AppData\Local\Temp\pana_73d49721\frb_dart\bin`...
INFO       Running `D:\flutter\bin\cache\dart-sdk\bin\dart.exe --no-analytics format --output=none --set-exit-if-changed --line-length 80 C:\Users\dbsx\AppData\Local\Temp\pana_73d49721\frb_dart\lib`...

## ✗ Follow Dart file conventions (20 / 30)
### [x] 0/10 points: Provide a valid `pubspec.yaml`

<details>
<summary>
Failed to verify repository URL.
</summary>

Please provide a valid [`repository`](https://dart.dev/tools/pub/pubspec#repository) URL in `pubspec.yaml`, such that:

 * `repository` can be cloned,
 * a clone of the repository contains a `pubspec.yaml`, which:,
    * contains `name: flutter_rust_bridge`,
    * contains a `version` property, and,
    * does not contain a `publish_to` property.

Unable to parse `pubspec.yaml` from git repository. Invalid argument(s): Path "frb_dart/pubspec.yaml" is not normalized.
</details>

### [*] 5/5 points: Provide a valid `README.md`

### [*] 5/5 points: Provide a valid `CHANGELOG.md`

### [*] 10/10 points: Use an OSI-approved license

Detected license: `MIT`.

## ✓ Provide documentation (10 / 10)
### [*] 10/10 points: Package has an example

## ✓ Platform support (20 / 20)
### [*] 20/20 points: Supports 6 of 6 possible platforms (**iOS**, **Android**, **Web**, **Windows**, **MacOS**, **Linux**)

* ✓ Android
* ✓ iOS
* ✓ Windows
* ✓ Linux
* ✓ MacOS
* ✓ Web

## ✓ Pass static analysis (30 / 30)
### [*] 30/30 points: code has no errors, warnings, lints, or formatting issues

## ✓ Support up-to-date dependencies (20 / 20)
### [*] 10/10 points: All of the package dependencies are supported in the latest version

|Package|Constraint|Compatible|Latest|
|:-|:-|:-|:-|
|[`args`]|`^2.3.1`|2.4.0|2.4.0|
|[`build_cli_annotations`]|`^2.1.0`|2.1.0|2.1.0|
|[`colorize`]|`^3.0.0`|3.0.0|3.0.0|
|[`js`]|`^0.6.4`|0.6.7|0.6.7|
|[`meta`]|`^1.3.0`|1.9.0|1.9.0|
|[`path`]|`^1.8.1`|1.8.3|1.8.3|
|[`puppeteer`]|`^2.12.0`|2.22.0|2.22.0|
|[`shelf`]|`^1.3.2`|1.4.0|1.4.0|
|[`shelf_static`]|`^1.1.1`|1.1.1|1.1.1|
|[`shelf_web_socket`]|`^1.0.2`|1.0.3|1.0.3|
|[`tuple`]|`^2.0.1`|2.0.1|2.0.1|
|[`uuid`]|`^3.0.6`|3.0.7|3.0.7|
|[`web_socket_channel`]|`^2.2.0`|2.3.0|2.3.0|
|[`yaml`]|`^3.1.1`|3.1.1|3.1.1|

<details><summary>Transitive dependencies</summary>

|Package|Constraint|Compatible|Latest|
|:-|:-|:-|:-|
|[`archive`]|-|3.3.6|3.3.6|
|[`async`]|-|2.10.0|2.10.0|
|[`collection`]|-|1.17.1|1.17.1|
|[`convert`]|-|3.1.1|3.1.1|
|[`crypto`]|-|3.0.2|3.0.2|
|[`http`]|-|0.13.5|0.13.5|
|[`http_parser`]|-|4.0.2|4.0.2|
|[`logging`]|-|1.1.1|1.1.1|
|[`mime`]|-|1.0.4|1.0.4|
|[`petitparser`]|-|5.2.0|5.2.0|
|[`pointycastle`]|-|3.6.2|3.6.2|
|[`pool`]|-|1.5.1|1.5.1|
|[`source_span`]|-|1.9.1|1.9.1|
|[`stack_trace`]|-|1.11.0|1.11.0|
|[`stream_channel`]|-|2.1.1|2.1.1|
|[`string_scanner`]|-|1.2.0|1.2.0|
|[`term_glyph`]|-|1.2.1|1.2.1|
|[`typed_data`]|-|1.3.1|1.3.1|
</details>

To reproduce run `dart pub outdated --no-dev-dependencies --up-to-date --no-dependency-overrides`.

[`args`]: https://pub.dev/packages/args
[`build_cli_annotations`]: https://pub.dev/packages/build_cli_annotations
[`colorize`]: https://pub.dev/packages/colorize
[`js`]: https://pub.dev/packages/js
[`meta`]: https://pub.dev/packages/meta
[`path`]: https://pub.dev/packages/path
[`puppeteer`]: https://pub.dev/packages/puppeteer
[`shelf`]: https://pub.dev/packages/shelf
[`shelf_static`]: https://pub.dev/packages/shelf_static
[`shelf_web_socket`]: https://pub.dev/packages/shelf_web_socket
[`tuple`]: https://pub.dev/packages/tuple
[`uuid`]: https://pub.dev/packages/uuid
[`web_socket_channel`]: https://pub.dev/packages/web_socket_channel
[`yaml`]: https://pub.dev/packages/yaml
[`archive`]: https://pub.dev/packages/archive
[`async`]: https://pub.dev/packages/async
[`collection`]: https://pub.dev/packages/collection
[`convert`]: https://pub.dev/packages/convert
[`crypto`]: https://pub.dev/packages/crypto
[`http`]: https://pub.dev/packages/http
[`http_parser`]: https://pub.dev/packages/http_parser
[`logging`]: https://pub.dev/packages/logging
[`mime`]: https://pub.dev/packages/mime
[`petitparser`]: https://pub.dev/packages/petitparser
[`pointycastle`]: https://pub.dev/packages/pointycastle
[`pool`]: https://pub.dev/packages/pool
[`source_span`]: https://pub.dev/packages/source_span
[`stack_trace`]: https://pub.dev/packages/stack_trace
[`stream_channel`]: https://pub.dev/packages/stream_channel
[`string_scanner`]: https://pub.dev/packages/string_scanner
[`term_glyph`]: https://pub.dev/packages/term_glyph
[`typed_data`]: https://pub.dev/packages/typed_data

### [*] 10/10 points: Package supports latest stable Dart and Flutter SDKs

## ✓ Support sound null safety (20 / 20)
### [*] 20/20 points: Package and dependencies are fully migrated to null safety!

Points: 120/130.
error: Recipe `dart_linter_pana` failed on line 166 with exit code 127

What does Path "frb_dart/pubspec.yaml" is not normalized. mean?

@fzyzcjy, everything is done. To sum up:

refine function generator::c::generate_dummy to solve the issue;
refine  function frb_codegen and add new frb_codegen_multi, which is also useful for development in the future;
after testing, still use static instead of inline for  API within  auto-generated c header file(s);
refine doc for using multi-blocks with iOS/MacOS.

Good job!

frb_codegen is for single-block
frb_codegen_multi for multi block
@dbsxdbsx - maybe we should update the doc to tell users how to use it? I guess we should add a few /// ... comments to frb_codegen and frb_codegen_multi, and briefly mention that users should read corresponding doc in our mini book

Hmm there was a reply here asking how to use it, but later it seems to be deleted by the author?

Hmm there was a reply here asking how to use it, but later it seems to be deleted by the author?

Yeah, I found in files

Hmm, it looks like here's a strange behaviour.
Our code root: https://github.com/broxus/nekoton_bridge/tree/attempt_generate_from_multiple_files/packages/nekoton_bridge
Look at files:
crypto/mnemonic/mnemonic_api.dart
crypto/encrypted_key/encrypted_key_api.dart
Both files have class MnemonicTypeG with _$MnemonicTypeG but on rust side both files look into native/src/nekoton/models_api.rs which in dart side doesn't contains such class.
And I still get duplicate error:
conflicting implementations of trait `flutter_rust_bridge::IntoDartExceptPrimitive` for type `nekoton::models_api::MnemonicTypeG`
   --> packages/nekoton_bridge/native/src/encrypted_key_generated.rs:81:1
    |
81  | impl support::IntoDartExceptPrimitive for MnemonicTypeG {}
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `nekoton::models_api::MnemonicTypeG`
    |
   ::: packages/nekoton_bridge/native/src/mnemonic_generated.rs:124:1
    |
124 | impl support::IntoDartExceptPrimitive for MnemonicTypeG {}
    | ------------------------------------------------------- first implementation here

frb_codegen is for single-block frb_codegen_multi for multi block
@dbsxdbsx - maybe we should update the doc to tell users how to use it? I guess we should add a few /// ... comments to frb_codegen and frb_codegen_multi, and briefly mention that users should read corresponding doc in our mini book

I think the doc with  /// ... is enough to explain frb_codegen_multi  and frb_codegen. I guess the signatures of the 2 functions are easy to read, right?
What about doing a little modification for the function docs like this:
/// when the API is only defined in 1 rust file(block), take this one for generation, where `config`
/// is the instance containing all information to the API file(block), and `all_symbols` contains
/// all unique APIs defined in the file mentioned above.
/// If APIs are defined in more than 1 rust file(block), use `frb_codegen_multi` instead.
pub fn frb_codegen(config: &config::Opts, all_symbols: &[String]) -> anyhow::Result<()> {
...
}

/// the function is used only for cases with multi-blocks when there are
/// more than 1 API block. And because the current block to deal with needs information
/// from all other blocks， so `all_configs` is used here,
/// with `index` refers to the place of the current block to deal with.
/// For details on how to take advantage of multi-blocks, please refers to this article: https://cjycode.com/flutter_rust_bridge/feature/multiple_files.html
pub fn frb_codegen_multi(
    all_configs: &[config::Opts],
    index: usize,
    all_symbols: &[String],
) -> anyhow::Result<()> {
...
}

Both files have class MnemonicTypeG with _$MnemonicTypeG but on rust side both files look into native/src/nekoton/models_api.rs which in dart side doesn't contains such class.

@Alex-A4, for your issue:

I wonder if this issue only occurs after updating to v1.65.1?(I notice that you used v1.64.0 before) If this is the case, it is weird, because I only update the generated c-header files, which should no effect other parts of frb.
Though I'm not familiar with the conflict issue with trait(I didn't implement generation for feature trait),  it seems that it is some conflict like this. Maybe it is a good time to review your issue again after the shared-part has been totally decoupled.

I think the doc with /// ... is enough to explain frb_codegen_multi  and frb_codegen.

I think so


Update NCA_Kim2011.py

Fixing #2744 to make sure we hit the voltage cut-off, instead of the particle stoichiometry going above 1.
Using the function in Kim2011 article to take the place of pybamm\input\parameters\lithium_ion\data\nca_ocp_Kim2011_data.csv for parameter 'Positive electrode OCP[V]' in Kim2011 parameter set.
The function 'nca_ocp_Kim2011(sto)' in pybamm\input\parameters\lithium_ion\NCA_Kim2011.py is edited.

Hmm, tests are failing because the old NCA Kim error was being used to test for the error reporting, if you feel confident to fix it I would suggest adding a different example where the interpolant extrapolates instead. I think something like this should work
x = np.linspace(0,2)
var = pybamm.Variable("var")
rhs = pybamm.Interpolant(x, x, var, name=name, interpolator="linear")
model = pybamm.BaseModel()
model.rhs[var] = rhs
model.initial_conditions[var] = 1
solver = pybamm.ScipySolver()
t_eval = [0,5]

# solution should grow exponentially and go above var=2, then the interpolant should error
solver.solve(model, t_eval)

Sorry, I don't know what 'old NCA Kim error was being used to test for the error reporting' means. Could you explain it in detail?

This test is failing since line 508 expects an error from the parameter set before you fixed it. https://github.com/pybamm-team/PyBaMM/blob/f45f4a5988da047ee356a29fc570475b1a110421/tests/unit/test_solvers/test_casadi_solver.py#L488-L509
Instead, we should test using a standalone piece of code like the one I shared above, and still make sure the error is raised

Although I still don't quite understand the reason and purpose of this test, I am very grateful for this update and your work.


add cicd pipeline (needs test)

pipeline seems to work now. add a deployment mechanism later (e.g. just a simple source deployment).


does it have fix for sound delay when windows is left idle

this issue
https://github.com/hainguyents13/mechvibes/issues/229

Are you asking a question or reporting an issue? I've never encountered this and I've never seen someone complain about this.

asking question.
I've encounter this issue with mechvibes. Did you use same build for MechvibesPlusPlus? I don't know what's difference between two software

Sorta, I've implemented a bunch more features and bug fixes. I've also enabled more diagnostic tools for bug reporting. Again, I've never encountered or heard of a bug like this though. Feel free to download and test yourself, and then create a new issue with the devtools log if you do find anything out of the ordinary.

already download, will use it for 1-2 weeks to see if see any issue happen.
Bythe way during installation some error appeared. I just ignore it and continue with installation.
I think error was regarding Microsoft visual Redistribution

If you already have Microsoft Visual C++ 2015-2019 installed, you should be fine.


Refactor: Global reduced motion rule

What does this PR do?
Adds a global rule for prefers-reduced-motion
Test Plan
Manual
Related PRs and Issues
N/A
Have you read the Contributing Guidelines on issues?
Yes

@TGlide once the conflict is gone we can merge :-)

@TGlide once the conflict is gone we can merge :-)

Done!


How do I configure Cloud Foundry Services Correct with Steeltoe?

Question
How do I configure Cloud Foundry Services Correct with Steeltoe? I am trying to use Steeltoe to get Data from Services in my Cloud Foundry. When I try to access the Credentials from the Service, die Values are empty objects. I try to access them over CloudFoundryServicesOptions.
Environment (please complete the following information):

.NET Version [.NET 6]
Steeltoe Version [3.2.1]

Additional context or links
Add any other context about the problem here.

Hi @DavidBohl-Nbg, can you please provide simple repro so we have a more complete picture of what you're trying to do?
It would help to know all the Steeltoe packages you're using (.csproj), how you're adding them (program.cs/startup.cs), how you're accessing CloudFoundryServicesOptions, and what service(s) you're binding in Cloud Foundry

Hi @TimHess ,
thank you for your fast resonse. Here is, how I use Steeltoe in my Project:
csproj
<Project Sdk="Microsoft.NET.Sdk.Web">

	<PropertyGroup>
		<TargetFramework>net6.0</TargetFramework>
		<Nullable>enable</Nullable>
		<ImplicitUsings>enable</ImplicitUsings>
	</PropertyGroup>

	<ItemGroup>
                ...
		<PackageReference Include="Steeltoe.Extensions.Configuration.CloudFoundryBase" Version="3.2.0" />
	</ItemGroup>
...
</Project>

Program.cs:
using MyProject.Options;
using Serilog;
using Steeltoe.Extensions.Configuration.CloudFoundry;

var builder = WebApplication.CreateBuilder(args);

builder.Configuration
    .AddCloudFoundry();

// Add services to the container.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services
    .AddOptions()
    .ConfigureCloudFoundryOptions(builder.Configuration)
    .AddEndpointsApiExplorer()
    .AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseSwagger();
app.UseSwaggerUI();

app.UseHttpsRedirection();

app.MapControllers();
app.Run();

vcap:services:
"user-provided": [
        {
          "name": "test-up",
          "credentials": {
            "Message": "Hello World!",
            "Title": "Test"
          }
        }
]

TestController.cs:
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Options;
using Steeltoe.Extensions.Configuration.CloudFoundry;

namespace MyProject.Controllers;

[ApiController]
[Route("api/v1/test")]
public class TestController : ControllerBase
{
    private CloudFoundryApplicationOptions _cloudFoundryApplicationOptions;
    private CloudFoundryServicesOptions _cloudFoundryServicesOptions;

    public TestController(IOptions<CloudFoundryApplicationOptions> appOptions, IOptions<CloudFoundryServicesOptions> servicesOptions)
    {
        _cloudFoundryApplicationOptions = appOptions.Value;
        _cloudFoundryServicesOptions = servicesOptions.Value;
    }

    [HttpGet]
    public async Task<IActionResult> Get()
    {
        return Ok(new List<object>() { _cloudFoundryServicesOptions.Services });
    }

}

Response from Controller:
[
  {
    "user-provided": [
      {
        "credentials": {
          "Message": {},
          "Title": {}
        },
        "configuratioN_PREFIX": "services",
        "name": "test-up",
        "label": null,
        "tags": null,
        "plan": null,
        "services": {}
      }
    ]
  }
]

Hi @TimHess,
thank you for providing these Tests. I figured out that my mistake was to use the IOptions Interface. It works when I configure the Services explicit and access them via IOptionsSnapshot. Thanks for your help!


Add unit test for refetchInterval to work properly

Help wanted :)
Add unit test for https://github.com/tannerlinsley/react-query/discussions/404, which should check that refetchInterval works properly, when parent component rerenders (See https://github.com/tannerlinsley/react-query/pull/399 for more info)

:tada: This issue has been resolved in version 1.5.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cinnamon: can't turn off screen.

Describe the bug
I set turn off the screen when incative fot 5 minutes.
When I am not active, after 5 minutes, the screen will close once and then open instantly.
Use xset can reproduce.
Steps To Reproduce
Steps to reproduce the behavior:
xset dpms force off

Expected behavior
Screen will close once and then open instantly.
Notify maintainers

@bobby285271
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.68, NixOS, 22.11 (Raccoon), 22.11.20220921.7537ce3`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.0`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Does sleep 2 && xset dpms force off also reproduce the issue for you?

@bobby285271 Yes, and try pantheon de reproduce too, but when use wm(dwm) just startx can’t reproduce, so maybe lightdm bug?


serialize embedded document with references associations

Hello,
I had to load my fixtures with some EmbeddedDocument with Associations but I could not.
So, I edited EmbeddedDocumentSerializer to fix that problem. But, I duplicated some code from UnitOfWork::flush() and DoctrineResolver::storeAssociationField(), so if someone could refactor this, it will be pretty cool. ;)
Thanks.

Closed in favor of #138


Feat/context directory

API changes
This PR updates the Function and FunctionArg from our engine API to support defaultPathFromContext
# Function

  withArg(
    """
    If the argument is a Directory or File type, default to load path from context directory, relative to root directory.
    """
    defaultPath String = ""

   ignore: [String!]
# }

# FunctionArg {

  """
  If the argument is a Directory or File type, default to load path from context directory, relative to root directory.
  """
  defaultPath: String!

  ignore: [String!]
# }

Engine changes

Update Call to load contextual values and insert it as input.
Add a loadContextualArg function that take the typedef and retrieve its contextual default value.
Add a function loadContext to load from git or local source the contextual path.
This implements the spec designed in #7647
For git: we load it from the context directory since it includes the whole repo.
For local: we load it from importLocal with the specific directory specified so we never load the full repo expect for /

Current progress

[x] Loading directory
[x] Get *Directory to ID: I found a workaround with Blob but it's not okay for File, I will check if I can use select instead.
[x] Load File, using Select actually works!
[x] Handle relative path
[x] Write tests
[x] Complete all SDK support

Spec Reminder

[x] The context directory is the git repository containing the module. If there is not git repository, the context is simply the module.
[x] Relative paths are relative to the current source file, scoped to the context directory for security
[x] Absolute paths are rooted in the context directory
[x] There is no limit to the number of directories which can have default values of this sort
[x] Optionally, directories can be filtered with a gitignore-style annotation

SDKs support

[x] Go using pragmas directive on Directory or File type ⌛

[x] Typescript using @argument({ defaultPath: "path", ignore: ["xx", "!xx"] }) ✅
Example

@func()
build(
  @argument({ defaultPath:"./frontend/src" }) frontend: Directory,
  @argument({ defaultPath:"./backend/app/src" }) backend: Directory,
  @argument({ defaultPath: "./tools/builder.conf" }) buildConfig: File,
): Directory {}

[x] Python using annotations

Fixes #7647

(continuing a conversation from discord)
For now, I think the way to general way to approach this feature should be to leave the current module context loading as is since it's used by the SDKs to build modules and then add this support for user arg context dirs as separate context loading calls. There's likely ways of unifying and optimizing this but better to start simple for now.
There's different ways of approaching this, I'm just gonna outline the first reasonable possibility that comes to mind. Not set in stone at all though so happy to hear other opinions and happy to help out more if reality of implementing it doesn't align with theory.

(discussed before) ModuleFunction has access to the Module and ModuleSource via this field: https://github.com/sipsma/dagger/blob/5231aa7de19266430581da054604ce533cc85898/core/modfunc.go#L25-L25
Add a new method to ModuleSource called something like LoadContext(path: string) (dagql.Instance[*Directory], error) that allows you to dynamically load dirs from the module source context.

This would be different than the existing ContextDirectory method that returns the static one loaded for the SDKs (we can consider renaming it maybe for clarity).
The way that you implement loading the context depends on whether it's coming from a remote git repo or a local git repo.

git is easy because we haven't implemented fancy dynamic loading, we just have to pull the whole repo, so you can just copy the directory from it's already loaded context dir
local is more involved since you will need to actually load it on demand. You can look at this code and the methods it calls to get an idea of how to do that (one of the really key parts being this section that does the load itself)

Another thing to be aware of is that the LocalImport call is sensitive to values passed in ctx which determine which client the dir should be loaded from. For now, we can just load from the "main client caller". I already wrote too much here, so just ping if you need pointers on this 🙂

Once that's in place, you can plug the arg in as a directory value same as others are (i.e. in this section)

This would be different than the existing ContextDirectory method that returns the static one loaded for the SDKs (we can consider renaming it maybe for clarity).

I understand this but this directory will not have the full repo if it's not part included in include, how do I workaround that?

This would be different than the existing ContextDirectory method that returns the static one loaded for the SDKs (we can consider renaming it maybe for clarity).

I understand this but this directory will not have the full repo if it's not part included in include, how do I workaround that?

You would need to add a new method that does the actual load of files from the original context directory (i.e. loads from the user's local dirs or loads from the git repo). That's what I was referring to under "The way that you implement loading the context depends on whether it's coming from a remote git repo or a local git repo." in my previous comment

Relative paths are relative to the current source file, scoped to the context directory for security

To do such thing, we need to know the file where the module func comes from, I'm not sure we got this information in the current API.
I think the resolution should be done by the SDK, what do you think @helderco @jedevc?

Relative paths are relative to the current source file, scoped to the context directory for security

To do such thing, we need to know the file where the module func comes from, I'm not sure we got this information in the current API. I think the resolution should be done by the SDK, what do you think @helderco @jedevc?

Sorry I forgot to update that line after further discussion. It should be relative to the module root, not the file (that would be too difficult to find out).

Sorry I forgot to update that line after further discussion. It should be relative to the module root, not the file (that would be too difficult to find out).

Ohh then yeah it's much easier haha

Another question @helderco @jedevc @shykes, should the API returns an error during registration if the typedef has both a default value and a contextual one?
This is possible in TypeScript and Python due to the notation so should this results in an error? I think so but I want your opinion.
Example of notation:
@func()
 async test(@context("/") dir: Directory = dag.directory()): Promise<string[]>

should the API returns an error during registration if the typedef has both a default value and a contextual one? This is possible in TypeScript and Python due to the notation so should this results in an error? I think so but I want your opinion.

I thought we were using default values? I might have missed (or forgotten) the last round of bikeshedding on that topic.

I thought we were using default values? I might have missed (or forgotten) the last round of bikeshedding on that topic.

No it's a specific field in the API, see the change of spec in the description

@TomChv could you add example snippets of what that feature would look like, in the 3 main languages please? It would make it easier to discuss the DX tradeoffs

I thought we were using default values? I might have missed (or forgotten) the last round of bikeshedding on that topic.

I updated my view in https://github.com/dagger/dagger/issues/7647#issuecomment-2174570033:

[...] warming up to not using the default value because of that as it makes an overall simpler implementation, just sacrificing on DX for SDKs that support default values, but that can be improved later.

[x]  Typescript using @context("path") ⚡ to be tested once the engine changes are completed
[ ]  Python using @context("path") ? To be confirmed by @helderco  ⌛

We need to bikeshed on the @context name.
In Python, this would have to be done using metadata annotation on the type:
def build(
    self,
    backend: Annotated[
        dagger.Directory,
        DefaultFromContext("../backend/app/src"),
        Ignore(...),
    ]
) -> dagger.Directory:
    ...

@TomChv could you add example snippets of what that feature would look like, in the 3 main languages please? It would make it easier to discuss the DX tradeoffs

I think it should look like this:
Go
func (app *App) Build(
  // +context="./frontend/src"
  frontend *Directory,
  // +context="./backend/app/src"
  backend *Directory,
  // +context="/tools/builder.conf"
  buildConfig *File,
) *Directory {}

Typescript
@func()
build(
  @context("./frontend/src") frontend: Directory,
  @context("./backend/app/src") backend: Directory,
  @context("./tools/builder.conf") buildConfig: File,
): Directory {}

Python
@function
def build(
  self,
  @context("./frontend/src") frontend: Directory,
  @context("./backend/app/src") backend: Directory,
  @context("./tools/builder.conf") build_config: File,
) -> Directory:

In Go, rather than // +context, it should be // +default.

@TomChv could you add an example of how regular default values work in each case?

@TomChv could you add an example of how regular default values work in each case?

Example on https://docs.dagger.io/manuals/developer/functions#default-values
Go
I'm not sure you can default to a directory value in Go so I don't know??
But for primitive type, you set a pragma like +default=4
Typescript
@func()
build(
  frontend: Directory = dag.directory(),
  backend: Directory = dag.directory(),
  buildConfig: File = dag.directory().WithNewFile("xxx", "xxx").File("xxx"),
): Directory {}

Python
I'm not sure about the syntax but probably:
def build(
  self,
  backend: Annotated[
     dagger.Directory,
  ] = dag.directory()
) -> dagger.Directory:
  ...

Few changes that we'll introduced on this PR based on my conversation with:

change @context to @argument with default and ignore metadata
support ignore as parameter
Move test to module_test.go because it's common to every SDK, not testing the API
Raise error if context & default is set, check inside TS SDK if context & default is set then throw error

@helderco
I've updated the PR with the new API and implement ignore.
All point above has been implemented 🚀

If I'm in a module in /foo (/ == git root) and the default path is /bar/man, the path is not resolved correctly:

Could I also see the code snippet and the tree view of the directory please? So I can make a repro locally

Test are failing due to 2 Python errors: https://dagger.cloud/dagger/traces/04e8dd584b027109a12f120f41a0e209?span=f60a702af34c8c5f
Nothing directly related to the PR, I can also see this issue on #7824

Test are failing due to 2 Python errors: https://dagger.cloud/dagger/traces/04e8dd584b027109a12f120f41a0e209?span=f60a702af34c8c5f
Nothing directly related to the PR, I can also see this issue on #7824

That's a known flake:

https://github.com/dagger/dagger/issues/7662

I continued your research based on your repro @jedevc and that's super weird.
Here's the dump of some logs I get when I try your repro:
During module loading:
2024-07-19 15:12:58 time="2024-07-19T13:12:58Z" level=error msg=moduleSource.ResolveContextPathFromCaller.rootSubpath rootSubPath=.
2024-07-19 15:12:58 time="2024-07-19T13:12:58Z" level=error msg=moduleSource.ResolveContextPathFromCaller.sourceRootAbsPath sourceRootAbsPath=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/git-ctx-dir/ctxmod
2024-07-19 15:12:58 time="2024-07-19T13:12:58Z" level=error msg=moduleSource.ResolveContextPathFromCaller.sourceRootAbsPath contextAbsPath=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/git-ctx-dir contextFound=true sourceRootAbsPath=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/git-ctx-dir/ctxmod

During context Dir loading:
2024-07-19 15:13:00 time="2024-07-19T13:13:00Z" level=error msg=moduleSource.ResolveContextPathFromCaller.rootSubpath rootSubPath=./ctxmod
2024-07-19 15:13:00 time="2024-07-19T13:13:00Z" level=warning msg="error resolving ctxmod.dirs: [String!]!" error="map[error:failed to load contextual arg \"root\": failed to load contextual directory \"/\": failed to resolve context path: failed to stat source root: failed to stat path: failed to receive file bytes message: rpc error: code = NotFound desc = rpc error: code = NotFound desc = stat path: lstat /Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/git-ctx-dir/ctxmod/ctxmod: no such file or directory kind:*fmt.wrapError stack:<nil>]"

The sourceRootPath has change between the two operations, how is that possible?

@TomChv I mentioned here what we should need to do to fix the problem: https://github.com/dagger/dagger/pull/7744#discussion_r1671111212

Yeah it does appear to be inconsistent whether SourceRootSubpath is made to be relative to the cwd or not

We do it for abs paths here https://github.com/sipsma/dagger/blob/6d2bd214bcf6c722399ef820c025193eafd9da0e/core/schema/modulesource.go#L49-L49
We do it during dagger init since it takes an explicit path to the new source: https://github.com/sipsma/dagger/blob/6d2bd214bcf6c722399ef820c025193eafd9da0e/cmd/dagger/module.go#L112-L112
But don't appear to for user-supplied relative paths when just using the -m flag https://github.com/sipsma/dagger/blob/6d2bd214bcf6c722399ef820c025193eafd9da0e/cmd/dagger/module.go#L575-L575
So it seems like we could get away with just fixing that last point.

I think we can just patch that issue as described for now. The rest of the discussion is about larger changes that could simplify things overall, but not needed in the short term.

@sipsma's point is correct - that should fix the weird directory loading case.
But, also just want to repeat my point from above, I think we also need to understand how to fix the following:

There's a very subtle issue with using this in this way. If we have a Directory and we call AsModule on it, then the path defined by this module has no corresponding context directory on the host, so we need to instead get it from the src.ContextDirectory().

The function getExplicitModuleSourceRef is pretty small, I tried some changes but it didn't fixed the issue.
It's related to where the user is, some buildkit func seems to depends on that so I'm trying to workaround it with a new function but it's not working as expected.
I'm doing a lot of context switch with #7864 which is really slowing my productivity, hopefully I get everything done by tomorrow

Ok so last friday we did a big exploration with @helderco to find the issue and it seems it's the related to the set of the sourceRootSubPath when calling ResolveFromCaller on the last initialization, the path is set to be relative to the context directory and no longer the user's location in its host (from where he calls the dagger CLI) which creates issues when resolving the path with ResolvePathFromCaller.
I'm going to fix this issue by updating this to keep the previous path instead of setting it to the relative.
https://github.com/dagger/dagger/blob/d9a15262229f1dba0aa53dbd0216908438331995/core/schema/modulesource.go#L893

The fails in the CI doesn't seem related to my PR, more flackiness:

https://dagger.cloud/dagger/traces/c62c35a0fea4e7ee46b82e36677052de?span=2719a2b8918be39f#25daada6376b1058
https://dagger.cloud/dagger/traces/c62c35a0fea4e7ee46b82e36677052de?span=2719a2b8918be39f#e3dca007344955fe

About the Test important, I'm super confused about it https://dagger.cloud/dagger/traces/4a3b8d288d9af71bcda3004c4c4c8637#76074fdc7901bd68, the test all works, but not test important??

There's an argument for doing blob conversion here in that it means contextual directories with equal contents will always be cached the same no matter their source. This can actually matter in cases like:

Local and git have same contents (i.e. local checkout of a git repo)
Getting the same directory from different git commits and/or forks of the same repo
Commonly reoccurring directories, "empty dir" being the most common I'd guess
But there's also overhead to blob-ification, so hard to say one is better than the other. If forced to choose I'd probably just leave this as is for now though.

So what should I do, I'm a bit confused

There's an argument for doing blob conversion here in that it means contextual directories with equal contents will always be cached the same no matter their source. This can actually matter in cases like:

Local and git have same contents (i.e. local checkout of a git repo)
Getting the same directory from different git commits and/or forks of the same repo
Commonly reoccurring directories, "empty dir" being the most common I'd guess
But there's also overhead to blob-ification, so hard to say one is better than the other. If forced to choose I'd probably just leave this as is for now though.

So what should I do, I'm a bit confused

GIthub's UI is making it hard to see, but to be clear that was a response to this earlier comment: https://github.com/dagger/dagger/pull/7744#discussion_r1668392984
But like I said at the end I'd just leave it as is, so no change.

Just rebased.

There's several places that need to take DefaultPath into consideration now, in order to know if an argument is optional or not.

Most importantly, in the CLI and in the codegen of all SDKs. Also needs test coverage for this.

Yeah, do you think it's doable in a follow up or it should be on this PR? I'm not sure I can update all the SDKs since the PR is already fairly big.

Yeah, do you think it's doable in a follow up or it should be on this PR? I'm not sure I can update all the SDKs since the PR is already fairly big.

Yeah, you you need to do it in this PR or it isn't ready. I'll add the Python codegen bit, you can handle Go and TypeScript.

Ohhh but it's already done in TypeScript
https://github.com/dagger/dagger/pull/7744/files#diff-4df8e2e3923a9ee4798a1fb594a383c303c92e3610e1f3e03a6a1f523ba244ecR143-R146
And in Go: https://github.com/dagger/dagger/pull/7744/files#diff-7733b13eee92afbeedff5903d1e7879b0454f9dbde3996c54ef6f70d65e11170R299

Ohhh but it's already done in TypeScript
https://github.com/dagger/dagger/pull/7744/files#diff-4df8e2e3923a9ee4798a1fb594a383c303c92e3610e1f3e03a6a1f523ba244ecR143-R146
And in Go: https://github.com/dagger/dagger/pull/7744/files#diff-7733b13eee92afbeedff5903d1e7879b0454f9dbde3996c54ef6f70d65e11170R299

You're right. It was late for me when I made that review trying it out locally. Got my wires crossed, sorry about that!
There's quite a few combinations of has default, is nullable, has default path, setting as optional even though it's not in code, etc... that it's better to offload all of this to the API, rather than every SDK having to get it right.

The +ignore pragma needs to specify all patterns in a single line. Is it possible to make it multiline? Something like:
func New(
	// +defaultPath="/"
	// +ignore=[
	//    "bin",
	//    ".git",
	//    "**/node_modules",
	//    "**/.venv",
	//    "**/dev/sdk",
	//    "**/__pycache__"
	//  ]
	source *dagger.Directory,
) (*DaggerDev, error) {
}

I need to check how I can parse that but that must be possible.

Hm, you want parsePragmaComment. This is tricky, currently it's all assumed in one line with a regexp.
Being able to do opening/closing braces means the language is no longer regular, so we won't be able to use regexp for it. I'm not confident there's a simple way to do it (but I'm happy to do it in a follow-up) - I don't think we should delay this PR for that though.

I'm not confident there's a simple way to do it (but I'm happy to do it in a follow-up) - I don't think we should delay this PR for that though.

Alright, I'm waiting for approvals and let's merge it :D

There’s something wrong when depending on a module that uses a context directory.
Example:
dagger-dev init --sdk=go test
dagger-dev init --sdk=go test/dep

// test/dep/main.go
package main

import "github.com/dagger/dagger/test/dep/internal/dagger"

type Dep struct{}

func (m *Dep) Test(
	// +defaultPath="/"
	// +ignore=["!test"]
	source *dagger.Directory,
) *dagger.Directory {
	return source
}

// test/main.go
package main

import "github.com/dagger/dagger/test/internal/dagger"

type Test struct{}

func (m *Test) Dep() *dagger.Directory {
	return dag.Dep().Test()
}

Calling dep directly uploads test from the absolute path for the context directory in my host:
❯ dagger-dev -v call -m test/dep test

✔ Dep.test: Directory! 0.3s
  ✔ upload /Users/helder/Projects/dagger from itvcgmpmay0maeo073750fp1j (client id: nkb4aqx9f17ve8p2d73tloq65, session id: ke5jlcudbg0uy9zizohjm6e37) (include: test) 0.1s

_type: Directory
entries:
    - test

But calling as a dependency, tries to upload from /scratch:
❯ dagger-dev -vvv call -m test dep

  ✔ Dep.test: Directory! 0.3s
    ✔ upload /scratch from kbzudk1n18ifj8vezs8o6h2jd (client id: w4cn43mbmxq5tublqyyvul7ae, session id: zv3pwm0sk60jn5fi6fa4apvrn) (include: test) 0.0s

_type: Directory
entries: []

Hmmm interesting, okay I need to dig into that! I didn't cover that kind of cases during my tests.

Ok so I've done some research into the engine and the issue make sense but is pretty complex to solve.
It seems that the environment dependencies are solved in different than the host's context.
For example, this is the values I get for a module called directly from host:
08-16 15:24:56 time="2024-08-16T13:24:56Z" level=error msg="ModuleSource.ResolveContextPathFromModule: get source root subpath" relHostPath=test/dep
2024-08-16 15:24:56 time="2024-08-16T13:24:56Z" level=error msg="ModuleSource.ResolveContextPathFromModule: stat caller host path" moduleRootAbsPath=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/context-dep/test/dep
2024-08-16 15:24:56 time="2024-08-16T13:24:56Z" level=error msg="ModuleSource.LoadContext: resolveContextPathFromModule" ctxPath=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/context-dep modPath=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/context-dep/test/dep path=/
2024-08-16 15:24:56 time="2024-08-16T13:24:56Z" level=error msg="ModuleSource.LoadContext: importing local module source" excludes="[]" includes="[test]" path=/Users/tomchauveau/Documents/github.com/quartz-technology/playground/e2e-tmp/context-dep

^^^Here as you see, the path matches with my host tree /Users/tomchauveau/xxxx
And this is the result when a module call a dependency that has a contextual argument:
2024-08-16 15:21:19 time="2024-08-16T13:21:19Z" level=debug msg="moduleFunction.loadContextualArg: loading contextual directory" dir=/ fn=source
2024-08-16 15:21:19 time="2024-08-16T13:21:19Z" level=error msg="ModuleSource.ResolveContextPathFromModule: get source root subpath" relHostPath=
2024-08-16 15:21:19 time="2024-08-16T13:21:19Z" level=error msg="ModuleSource.ResolveContextPathFromModule: stat caller host path" moduleRootAbsPath=/scratch
2024-08-16 15:21:19 time="2024-08-16T13:21:19Z" level=error msg="ModuleSource.LoadContext: resolveContextPathFromModule" ctxPath=/scratch modPath=/scratch path=/
2024-08-16 15:21:19 time="2024-08-16T13:21:19Z" level=error msg="ModuleSource.LoadContext: importing local module source" excludes="[]" includes="[test]" path=/scratch

^^^Here, it's /scratch, because I think the context module isn't the host, but a container inside the engine that execute the module.
So, to fix this issue, we must find a way to insert the host context to the dep's container, however, I have no idea how to do such thing, I'll need some help to accomplish that.
@sipsma @jedevc @vito, do you have any idea?

@jedevc @TomChv I pulled this PR locally, will try the repro from @helderco and see if I can get a fix working (or at least an outline).
Disclaimer: There's a reasonable likelihood I'm still missing a detail or just repeating what was stated above, still catching up on everything.
But FWICT generally speaking the caching concerns around keeping track of client IDs in order to know where to pull module source from for context dirs feels like the same problem as the ones around secrets+sockets.
The general solution we have for this is:

Get a "content-defined key" for the resource

For secrets, it's the dagql ID digest for the call that creates the secret
For sockets, it's the dagql ID digest for the call that creates the socket

Put the "not content-defined" or mutable data in a "Store" that maps the above key to the out-of-band data. Stores are part of session+client state.

For secrets, we put the actual secret plaintext as the value in the store
For sockets, we put the metadata for the socket (path for unix, addr/port for ip) as the value in the store

Pass the "content-defined key" around the API calls (caching works because it's content defined) and when an API implementation needs to access the associated metadata, read it from the store using that key.

I think the solution to this problem has the same outline, except it's probably even simpler:

Use the module source digest as the "content-defined key" - we already rely on this digest's stability
Add a new "Store" (really just a map) to the session state that maps module source digest -> metadata required to load contextual dir

For local source modules, that metadata would include the client ID. For git source modules, just the dagql ID of the module source would suffice.

When setting up the module function call, ensure we get that module source digest and use it to look up the metadata in the store, loading the directory synchronously at that time and providing that dir as the argument.

Like I said though, trying this locally to ensure theory aligns with reality.

Update:
Have a rough implementation of the idea described in the previous comment.

This was all said and done extremely simple, diff here
It's not beautiful yet, but fine. I have ideas on more aesthetically pleasing approaches but not worth it on top of this already large effort IMO.
There's some fixes needed to ensure that the actual paths we use in each case are always based on the "callees" paths when a dep, but the important part of using the right client is fixed.

After re-reading previous comments and catching up on discord conversations, I see also the issue where you could have:

multiple modules with the exact same digest due to having same name, same source code, etc.
different contextual files/dirs (i.e. not those loaded to initialize the module itself but that can be loaded by context dir args)
all loaded into the same session (via dagger-in-dagger)

In this type of case, using the module source digest would result in multiple modules having the same digest in the same session and thus could result in inconsistent contextual dir loads if there are differences between the modules.

Let me know if a concrete example would be helpful here, I realize this is all a bit abstract

The thing is, I really struggle to imagine why we or users should ever care about this. It's such an absurdly obscure situation outside of our own integ tests that I personally can't justify us spending time worrying about it. Unless I'm missing something, I think it would be a huge waste of everyone's time.
Instead, we can just make some trivial adjustments to our integ tests if it is indeed an issue. Something as simple as giving each module a unique name would fix this (and tbh wouldn't be surprised if it fixes other flakes https://github.com/dagger/dagger/issues/8184).

To summarize:

I think we can go with the diff that fixes deps to use the right client IDs. It avoids the cache invalidation problems.

There's separate fixes needed to ensure deps use the right paths, but should be a trivial addition on top of that.

The only thing I can imagine hitting it is our own integ tests and that can be fixed in trivial ways such as just using module names unique to each test.

cc @TomChv @jedevc @shykes @vito

Okay turns out that approach had problems involving caching that made it not worth salvaging. Basically, dagql caching resulted in clients not always getting registered and old clients from nested execs to be used when they had already exited.
Fortunately, I think found something much much simpler and more robust, pushed to this PR here: https://github.com/dagger/dagger/pull/7744/commits/b8220368ff27312986c4adac3df1de977360a639
The idea is that a chain of module calls involving transitive deps always looks something like:

Non-module client calling a module (i.e. dagger call on the host, or in a nested exec in the case of our integ tests)
Module client calling a dep
Dep being called (and possibly using contextual args)

If the dep is a local module and thus needs context loaded from local dirs, then the parent module must have also been loaded from the same local context. That parent module in turn must have been loaded from the original non-module client.
Basically, to find the client to load local context from, just walk client callers backwards until you find a non-module client.
The existing integ tests pass and I added a new one (just go so far) to cover this dep case, which also passes.

Would love to have this also supported in go sdk :)

It is supported in the go sdk. See the go examples in https://docs.dagger.io/manuals/developer/functions/#directories-and-files.

Thanks, I was confused by https://docs.dagger.io/manuals/developer/entrypoint-function#default-values-for-complex-types


AL0685: FlowFields causing warnings

We are currently moving out of the Microsoft objects (Universal Code Initiative). Our system is set up to return errors on certain warnings, especially those that can lead to runtime errors. One of these errors code is AL0685, where we currently have found 8 instances in BC21 (see below).
A clean up of these warnings would be much appreciated.
Rating.Table.al
The length '250' of the calculation formula's target field 'Description' is greater than the length '100' of the source flow field '"Profile Question Description"'. This could result in a runtime error.
BankExportImportSetup.Table.al
The length '249' of the calculation formula's target field 'Object Caption' is greater than the length '80' of the source flow field '"Processing Codeunit Name"'. This could result in a runtime error.
BankExportImportSetup.Table.al
The length '249' of the calculation formula's target field 'Object Caption' is greater than the length '80' of the source flow field '"Processing XMLport Name"'. This could result in a runtime error.
BankExportImportSetup.Table.al
The length '249' of the calculation formula's target field 'Object Caption' is greater than the length '30' of the source flow field '"Check Export Codeunit Name"'. This could result in a runtime error.
ConfigTemplateLine.Table.al
The length '100' of the calculation formula's target field 'Description' is greater than the length '50' of the source flow field '"Template Description"'. This could result in a runtime error.
CRMAccount.Table.al
The length '160' of the calculation formula's target field 'Name' is greater than the length '100' of the source flow field 'AccountStatiticsName'. This could result in a runtime error.
CustomReportLayout.Table.al
The length '249' of the calculation formula's target field 'Object Caption' is greater than the length '80' of the source flow field '"Report Name"'. This could result in a runtime error.
DataExchFieldMapping.Table.al
The length '80' of the calculation formula's target field 'Field Caption' is greater than the length '30' of the source flow field '"Target Field Caption"'. This could result in a runtime error.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 10731.


Add UDF engine_id

1. Describe the feature

engine_id means the sparkContext.conf.get("spark.app.id")
add doc too

2. Motivation
system information functions
3. Describe the solution
4. Additional context

I would like it.


[TF:TRT] Fix TF-TRT OSS Components Build

@bixia1

I am getting this error when trying to manually merge it
WARN: Cannot migrate http://github.com/tensorflow/tensorflow/pull/53325 because it is missing the following labels: [cla: yes]


brb: Disable universal links in BRBConnectionHandler

Disable universal links in the webview associated with the BRBConnectionHandler by using this hack?
Xcode did a bunch of cleanup as well I guess

None of them are in files that I touched so I don't particularly want to fix them.
They ought to be fixed in another PR, in my opinion


Prepare release branch for v4.63.2 of azure-cosmos and v4.33.1 of azure-cosmos-spark.

As title.

API change check
API changes are not detected in this pull request.

/azp run java - cosmos - ci

Corresponding CI run - https://dev.azure.com/azure-sdk/public/_build/results?buildId=4077247&view=results


added raw html output to display html pasts as html

add /html to the url for "text/html" output like /raw for "text/plain" output

Cool idea, just one small fix :)

merged via https://github.com/jfrazelle/pastebinit/commit/a2648cd20fff8b99f6cf07c40d18e2f8e1a62a7f thanks


Got null pointerException when running javafx:jlink

Hello running mvn javafx:jlink on my project I got the following NullpointerException
Caused by: java.lang.NullPointerException
at org.openjfx.JavaFXBaseMojo.getExecutablePath (JavaFXBaseMojo.java:368)
at org.openjfx.JavaFXJLinkMojo.execute (JavaFXJLinkMojo.java:154)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Any hints on what is going from ?

Please share your POM

I have used the simple way to configure openjfx plugin

		<plugin>
			<groupId>org.openjfx</groupId>
			<artifactId>javafx-maven-plugin</artifactId>
			<version>0.0.4</version>
			<configuration>
				<mainClass>com.ljo.Jaso.gui.Standalone</mainClass>
			</configuration>
		</plugin>

And also a more sophisticated way, but got exactly the same result

  <plugin>

			<groupId>org.openjfx</groupId>
			<artifactId>javafx-maven-plugin</artifactId>
			<version>0.0.4</version>
			<configuration>
				<mainClass>com.ljo.Jaso.gui.Standalone</mainClass>
				<stripDebug>true</stripDebug>
				<compress>2</compress>
				<noHeaderFiles>true</noHeaderFiles>
				<noManPages>true</noManPages>
				<launcher>JasoUI_openjfx</launcher>
				<jlinkImageName>openjfx</jlinkImageName>
				<jlinkZipName>JasoUI_openjfx_zip</jlinkZipName>
			</configuration>
		</plugin>

I can't to reproduce your issue neither in Windows nor in Linux using both configurations

I can't to reproduce your issue neither in Windows nor in Linux using both configurations

Running the goal from IntelliJ IDEA I got the same problem

I'm running into the same error. Here is the complete POM:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>protocol-handler</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.openjfx</groupId>
            <artifactId>javafx-controls</artifactId>
            <version>14</version>
        </dependency>
        <dependency>
            <groupId>org.openjfx</groupId>
            <artifactId>javafx-fxml</artifactId>
            <version>14</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <release>11</release>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.openjfx</groupId>
                <artifactId>javafx-maven-plugin</artifactId>
                <version>0.0.4</version>
                <configuration>
                    <release>11</release>
                    <jlinkImageName>swhrldm</jlinkImageName>
                    <launcher>launcher</launcher>
                    <executable>C:\Program Files\Java\jdk-14\bin\java.exe</executable>
                    <mainClass>org.example.App</mainClass>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

@matthjes from CMD or form an IDE?
I've only had this error once running javafx:jlink from IntelliJ and I don't know why, because it never happened to me again.

Hello, I guess this is due to JAVA_HOME is defined with the brackets like
JAVA_HOME="C:...."

Hello, I guess this is due to JAVA_HOME is defined with the brackets like
JAVA_HOME="C:...."
then : javaHomeFromEnv.concat(File.separator).concat("bin") produce unreadable path

If you are talking about this:
<executable>C:\Program Files\Java\jdk-14\bin\java.exe</executable>
I did tests with a path like that and work fine.

Not exactly, if JAVA_HOME env variable defined NPE will rise despite plugin executable tag.
I would suggest sanitizing env by improving getJavaHomeEnv in JavaFXBaseMojo
	private String getJavaHomeEnv(Map<String, String> enviro) { 		final String java_home = enviro.get("JAVA_HOME"); 		if (java_home != null) { 			String trimmedJavaHome = java_home.replace('\"',' ').replace('\'',' ').trim(); 			final Path path = Paths.get(trimmedJavaHome).normalize().toAbsolutePath(); 			if(!Files.isDirectory(path)){ 				throw new IllegalStateException("JAVA_HOME defined incorrectly:"+path); 			} 			return path.toString(); 		} 		return null; 	}

If JAVA_HOME env variable defined with quotes NPE will rise despite plugin executable tag

Double quotes are required if the ENV variable value contain white spaces, because of this when it is loaded by language are removed.
JAVA_HOME definition

Plugin configuration
<plugin>
	<groupId>org.openjfx</groupId>
	<artifactId>javafx-maven-plugin</artifactId>
        <!-- Version for test, same base of code as 0.0.4 -->
	<version>0.0.5-SNAPSHOT</version>
	<configuration>
		<release>11</release>
		<jlinkImageName>swhrldm</jlinkImageName>
		<launcher>launcher</launcher>
		<executable>D:\tools\java\adoptopenjdk 13+33_hotspot\bin\java.exe</executable>
		<mainClass>test.app/com.betanzos.App</mainClass>
	</configuration>
</plugin>

Then I have modified the JavaFXBaseMojo.getJavaHomeEnv() method in order to print the value it returns
private String getJavaHomeEnv(Map<String, String> enviro) {
    System.out.println("JavaFXBaseMojo.getJavaHomeEnv(): <" + enviro.get("JAVA_HOME") + ">");
    return enviro.get("JAVA_HOME");
}

And this is the javafx:jlink output

You may notice that the double quotes are not present, so they are not the cause of the problem.

C:\Users\denis>set JAVA_HOME="C:\Program Files\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot"
C:\Users\denis>echo %JAVA_HOME%
"C:\Program Files\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot"
Make sure echo produce an output with double quotes, then "mvn clean install"
Also, I didn't test with an "executable" tag so better to remove it to clean reproduce

Defines JAVA_HOME in this way no requires double quotes for handle withe spaces, so the value is wrong and Maven cannot work with it.

I think that this type of problem should not be handled by the plugin since it is a problem of bad configuration of the environment variable since this value is not a valid path.

In my case maven not complaining, only the plugin produces NPE.

In my case maven not complaining, only the plugin produces NPE.

Can you share the output of the command mvn --version?

Do we have clear instruction somewhere in README that you must do mvn --version to validate the environement before using a plugin ?

No, this not about the plugin, that is a useful command to know the configuration of our maven.

Well, I gave you clear steps to reproduce NPE, if you don't want to fix, up to you, I only sympathize with those who fall for it without any clue.

Yes, but I do not agree to fix a problem related to an wrong configuration of the development environment. So I want to see your mvn --version output since you say that maven is going well for you.
Anyway, you are free to open a PR with your proposal of fix.

mvn -version show me that the environment is wrong, but mvn clean install with a plugin - don't.
A plugin is used by people, people can do mistakes, and it is a good practice at least to tell what exactly goes wrong.

As I said, this is an environment configuration problem due to an invalid path and in my case all commands fail. If you disagree with me please make a PR.

Hello,
here are my cases:
set JAVA_HOME="C:\PROGRA~1\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot dummy" mvn clean install
dummy""=="" was unexpected at this time.
set JAVA_HOME="C:\PROGRA~1\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot" mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Users\denis\data\apache-maven-3.6.3\bin..
Java version: 14, vendor: AdoptOpenJDK, runtime: C:\PROGRA~1\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
set JAVA_HOME="C:\PROGRA~1\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot" mvn clean install
[ERROR] Failed to execute goal org.openjfx:javafx-maven-plugin:0.0.4:jlink (default) on project fx-bo-common-blog: Execution default of goal org.openjfx:javafx-maven-plugin:0.0.4:jlink failed.: NullPointerException -> [Help 1]
set JAVA_HOME=C:\PROGRA~1\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot mvn clean install
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

This is a good point:

set JAVA_HOME="C:\PROGRA~1\AdoptOpenJDK\jdk-<IP_ADDRESS>-hotspot"

In this case the plugin should work fine since Maven does. Because of this I'll make a PR fixing it.

Now work fine


Create a new bot wizard

https://microsoft.sharepoint.com/:w:/t/ConversationalAI785/ETsDy4Suj-9GvHuG9ZIL098B-8HysSMFmrqzBPkyjh3h5Q?rtime=pz8a4Pwh10g

This will sit on the Backlog for now


Global before hook except for 1 page

I would like to use the global before hook to check if I have a valid login session:
router.hooks({
        before: function (done, params) {
            if (global.sessionId === -1) {
                router.navigate('/login/');
                return;
            }

            done();
        }
    });

This creates an infinite loop, because even on the login page the sessionId is -1. Since I want my full website to be protected by this sessionId check, I would like to know how I can have this global hook for every route except for the /login/ route. Thanks in advance!

With the latest 8.0.0 release you'll be able to do the following:
router.hooks({
    before: function (done, match) {
      if (window.sessionId === -1 && match.url !== "login") {
        console.log("redirect to login");
        router.navigate("/login");
        return;
      }
      done();
    },
  });

The second argument of the hook is a Match object. You can use its url field to check what's the path that matched.
P.S.
as of today version 8.0.0 is not released officially. You could have the beta one by running yarn add navigo@beta.


fix(template): capturenode chidlist

Ref: https://github.com/unfoldadmin/django-unfold/issues/839

Below you can see that CaptureNode is inheriting from Node which already implements child_nodelists = ("nodelist",). I tested if the value is set in __init__ and it worked. Are we sure that the PR is really fixing your issue?
https://github.com/unfoldadmin/django-unfold/blob/main/src/unfold/templatetags/unfold.py#L79
https://github.com/django/django/blob/c56e1273a9d87ffad3a84fb597550f79b9820281/django/template/base.py#L960


Add build information for Ubuntu

We should document requied packages for installing on Ubuntu and Debian
to match up with the use on Fedora.
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

This fixes https://github.com/projectatomic/buildah/issues/243

@alexellis PTAL and verify that these commands would work for you on Ubuntu.

@alexellis @TomSweeneyRedHat PTAL and see if these commands work on Ubuntu

I'll try building this in a trusty container (so it's a repeatable build) and get back to you.

https://gist.github.com/alexellis/51e83db74ca18c6c07e00fafc766a9b3
Failure pulling in deps:
 ---> Running in e3c5e3c94d8b
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package bats
E: Unable to locate package libostree-dev
The command '/bin/sh -c apt-get -qy install bats btrfs-tools git libapparmor-dev libdevmapper-dev libglib2.0-dev libgpgme11-dev libostree-dev libseccomp-dev libselinux1-dev' returned a non-zero code: 100

add-apt-repository ppa:alexlarsson/flatpak
is supposed to make that available?

If you build with TAGS="containers_image_ostree_stub apparmor seccomp"
It should build without using the libostree.  And buildah really does not need that.

@alexellis The flatpak PPA only contains ostree builds for xenial and later.  IIRC trusty's version of libseccomp is too old for the version of the Go bindings for it that we end up pulling in.

I tried a new gist with Xenial as the base image and got a bit further, but there's still things missing.
make[1]: Entering directory '/root/go/src/github.com/projectatomic/buildah/docs'
go-md2man -in buildah.md -out buildah.1
Makefile:9: recipe for target 'buildah.1' failed
make[1]: go-md2man: Command not found
make[1]: *** [buildah.1] Error 127
make: *** [docs] Error 2

Well that is a lot further.
Do make install.tools
And that should get you go-md2man.

make install.tools didn't work.. perhaps one of you guys could get this to a working state from the gist? I don't know the dependencies well enough and we're just playing GitHub 🎾

Step 15/17 : RUN PATH=/usr/lib/go-1.8/bin:$PATH make install.tools && make runc all TAGS="apparmor seccomp"
 ---> Running in e5b9f6a72c56
go get -u -tags " libdm_no_deferred_remove seccomp" github.com/cpuguy83/go-md2man
go get -u -tags " libdm_no_deferred_remove seccomp" github.com/vbatts/git-validation
go get -u -tags " libdm_no_deferred_remove seccomp" gopkg.in/alecthomas/gometalinter.v1
gometalinter.v1 -i
make: gometalinter.v1: Command not found
make: *** [install.tools] Error 127
Makefile:53: recipe for target 'install.tools' failed
The command '/bin/sh -c PATH=/usr/lib/go-1.8/bin:$PATH make install.tools && make runc all TAGS="apparmor seccomp"' returned a non-zero code: 2

I added the install for go-md2man and was able to get buildah help working on Ubuntu, but ran into a segfault when trying to do any buildah from command:
sudo buildah bud -t whale .
STEP 1: FROM docker/whalesay:latest
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x7f7f26]
goroutine 1 [running]:
github.com/projectatomic/buildah/vendor/github.com/containers/image/transports.ImageName(0x0, 0x0, 0xc4200b6fe5, 0x16)
/home/tom/buildah/src/github.com/projectatomic/buildah/vendor/github.com/containers/image/transports/transports.go:71 +0x26
github.com/projectatomic/buildah.newBuilder(0x10781e0, 0xc42041b320, 0xc4200b6fe5, 0x16, 0x0, 0x0, 0x0, 0x0, 0x0, 0xb254f2, ...)
/home/tom/buildah/src/github.com/projectatomic/buildah/new.go:82 +0x1620
github.com/projectatomic/buildah.NewBuilder(0x10781e0, 0xc42041b320, 0xc4200b6fe5, 0x16, 0x0, 0x0, 0x0, 0x0, 0x0, 0xb254f2, ...)
/home/tom/buildah/src/github.com/projectatomic/buildah/buildah.go:154 +0x6d
github.com/projectatomic/buildah/imagebuildah.(*Executor).Prepare(0xc4202ac000, 0xc420072000, 0xc42048dab0, 0xc4200b6fe5, 0x16, 0x0, 0x0)
/home/tom/buildah/src/github.com/projectatomic/buildah/imagebuildah/build.go:472 +0x1f5
github.com/projectatomic/buildah/imagebuildah.(*Executor).Build(0xc4202ac000, 0xc420072000, 0xc420166fa0, 0x1, 0x1, 0x0, 0x0)
/home/tom/buildah/src/github.com/projectatomic/buildah/imagebuildah/build.go:640 +0xdb
github.com/projectatomic/buildah/imagebuildah.BuildReadClosers(0x10781e0, 0xc42041b320, 0xc4204410c0, 0x36, 0x0, 0x0, 0x0, 0xb254f2, 0x9, 0x0, ...)
/home/tom/buildah/src/github.com/projectatomic/buildah/imagebuildah/build.go:680 +0x488
github.com/projectatomic/buildah/imagebuildah.BuildDockerfiles(0x10781e0, 0xc42041b320, 0xc4204410c0, 0x36, 0x0, 0x0, 0x0, 0xb254f2, 0x9, 0x0, ...)
/home/tom/buildah/src/github.com/projectatomic/buildah/imagebuildah/build.go:727 +0xc11
main.budCmd(0xc42048e3c0, 0x0, 0x0)
/home/tom/buildah/src/github.com/projectatomic/buildah/cmd/buildah/bud.go:226 +0x855
github.com/projectatomic/buildah/vendor/github.com/urfave/cli.HandleAction(0xa43fc0, 0xb50300, 0xc42048e3c0, 0xc42033db00, 0x0)
/home/tom/buildah/src/github.com/projectatomic/buildah/vendor/github.com/urfave/cli/app.go:485 +0xd4
github.com/projectatomic/buildah/vendor/github.com/urfave/cli.Command.Run(0xb2dbfd, 0x16, 0x0, 0x0, 0x104db90, 0x1, 0x1, 0xb41fcd, 0x31, 0x0, ...)
/home/tom/buildah/src/github.com/projectatomic/buildah/vendor/github.com/urfave/cli/command.go:207 +0xb72
github.com/projectatomic/buildah/vendor/github.com/urfave/cli.(*App).Run(0xc4202beb60, 0xc4200100f0, 0x5, 0x5, 0x0, 0x0)
/home/tom/buildah/src/github.com/projectatomic/buildah/vendor/github.com/urfave/cli/app.go:250 +0x7d0
main.main()
/home/tom/buildah/src/github.com/projectatomic/buildah/cmd/buildah/main.go:93 +0xabe

I would love to start playing with this... possibly to do builds for OpenFaaS. Please could someone help us come to a working Docker build?

I managed to get a Docker image built, but when I use it, I get an error about overlay:
ERRO[0000] 'overlay' is not supported over overlay
ERRO[0000] 'overlay' is not supported over overlay
ERRO[0000] 'overlay' is not supported over overlay: backing file system is unsupported for this graph driver
'overlay' is not supported over overlay: backing file system is unsupported for this graph driver

You have to volume mount in /var/lib/containers into your container, otherwize you are doing Overlay over Overlay.

@lsm5 PTAL

@TomSweeneyRedHat Were you able to get any further with the invalid memory issue on Ubuntu?
@nalind Any ideas on this?

@rhatdan I've not gotten closer to finding the issue.  I pinged lsm5 to talk it through and we discovered that the kit he builds in ppa is also having troubles.  I've been testing his newer spins while he works through that.  Once that works I hope to see what he did to build the kit and see if we use that here.

running into some build issues trying to bump buildah to 0.3 on zesty and
xenial. Let me get back in a bit
On Fri, Aug 25, 2017 at 01:49:58PM +0000, Tom Sweeney wrote:

TomSweeneyRedHat commented on this pull request.

apt-get install software-properties-common

add-apt-repository ppa:duggan/bats
add-apt-repository ppa:alexlarsson/flatpak
add-apt-repository ppa:gophers/archive
apt-get install bats btrfs-tools git libapparmor-dev libdevmapper-dev libglib2.0-dev libgpgme11-dev libostree-dev libseccomp-dev libselinux1-dev
apt-get install golang-1.8
+```
+Then to install buildah on Ubuntu/Debian follow the steps in this example:

+```

mkdir ~/buildah
cd ~/buildah
export GOPATH=pwd
git clone https://github.com/projectatomic/buildah ./src/github.com/projectatomic/buildah
cd ./src/github.com/projectatomic/buildah
PATH=/usr/lib/go-1.8/bin:$PATH make runc all TAGS="apparmor seccomp"

ok, maybe it's an ubuntu thing, haven't run into this on other platforms.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/projectatomic/buildah/pull/244#discussion_r135262923

--
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

Is it possible to build images within a Docker image using an unprivileged buildah container?

@alexellis Depends on what you define as "unprivileged",  buildah will require the SYS_ADMIN privilege because it needs to mount file systems.  This would also cause a looser SELinux policy to be added, something we are investigating.  Finally /var/lib/containers/storage would need to be mounted into the container.
Other confinement would still be allowed.

@TomSweeneyRedHat I've updated buildah to the latest master branch on zesty and
xenial in the PPA.
If the PPA deb gets installed and works fine for you, that'll give me a better
picture on this PR.
On Tue, Aug 29, 2017 at 03:26:27AM -0700, Daniel J Walsh wrote:

@alexellis Depends on what you define as "unprivileged",  buildah will require the SYS_ADMIN privilege because it needs to mount file systems.  This would also cause a looser SELinux policy to be added, something we are investigating.  Finally /var/lib/containers/storage would need to be mounted into the container.
Other confinement would still be allowed.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/projectatomic/buildah/pull/244#issuecomment-325622618

--
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

@TomSweeneyRedHat PTAL

@lsm5 PTAL

On Mon, Sep 04, 2017 at 06:31:22PM +0000, Tom Sweeney wrote:

TomSweeneyRedHat commented on this pull request.

@@ -66,6 +67,30 @@ Then to install buildah follow the steps in this example:
buildah --help

+In Ubuntu/Debian, you can use this command:
+
+```
+  apt-get -y install software-properties-common
+  add-apt-repository -y ppa:duggan/bats
+  add-apt-repository -y ppa:alexlarsson/flatpak
+  add-apt-repository -y ppa:gophers/archive
+  apt-add-repository -y ppa:projectatomic/ppa
+  apt-get -y -qq update

Just tested on a UBUNTU server on my work pc and Buildah was up and running afterwards, but this update line threw up a bit.  @lsm5, any thoughts?  I think overall it LGTM and we should ship now and tweak as necessary later on.

root@ubuntu:~# apt-get -y -qq update
W: The repository 'http://ppa.launchpad.net/duggan/bats/ubuntu zesty Release' does not have a Release file.
E: Failed to fetch http://ppa.launchpad.net/duggan/bats/ubuntu/dists/zesty/main/binary-i386/Packages  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.

That's because there's nothing for zesty yet in that ppa.
See: http://ppa.launchpad.net/duggan/bats/ubuntu/dists/
What package do you need that for?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/projectatomic/buildah/pull/244#pullrequestreview-60458434

--
Lokesh
Freenode, OFTC: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

Merging.

@rh-atomic-bot r+ 1c8545f

@lsm5 I just tested and did not include this step:
add-apt-repository -y ppa:duggan/bats
Everything built fine and I did not get any of the errors I was seeing earlier.
If the bot merges this automatically, I'll go back and remove that line in a follow up PR., I don't think it's necessary.

Removed bats line.

@rh-atomic-bot retest

@rh-atomic-bot retest

@cevich PTAL

### Wed Sep  6 10:32:08 UTC 2017
### PR #244
### BUILD_ID 13657
...
BDB1539 Build signature doesn't match environment failed loading RPMDB

That appears exceptionally bad to me, did the VM run out of disk space or somesuch?
I really have no idea TBH, probably need to ask @jlebon if he has any guesses 😖

Yeah, this is a known issue right now with the Fedora 26 Docker image: https://bugzilla.redhat.com/show_bug.cgi?id=1483553.
For examples on how to work around it temporarily, see:
https://github.com/ostreedev/ostree/pull/1143
https://github.com/projectatomic/rpm-ostree/pull/975

Thx Jon, there's your answer @rhatdan 😀

FWIW, I vote to merge this as is.  There's not code changes, only documentation and the build issue is completely unrelated.

Merging since the tests are unrelated.


backpropagation when Rotate_IOU = 0

Hi,  @lilanxiao
I have question about backpropagation when rotate_IOU value is zero, a case when the number of vertices that intersect or inside another box are less than 3 .
How do you manage to backpropagate?

Hi, @JJangD
In this case, both the IoU value and its gradient are zero.
That is actually the problem if IoU is used directly as a loss: if there is no intersection, there is no gradient and the learnable parameters would not be updated. And that's why people use generalized IoU loss (G-IoU loss) or distance IoU loss (D-IoU loss). Basically, these loss functions take more information into account (the area of the minimal enclosing box of the two boxes or the distance between the centers of the boxes) to make sure the gradient is non-zero even no intersection exists.

@lilanxiao
Thanks for your reply.
I understood that the there will be no gradient updates to the box parameters such as x,y,w,h,th.
But I'm confused.
For example, let's say simply S = w x h and w = 0 , h = 5.
In this case, it would be S = 0. But gradient dS/dw = 5
Although, I think it would be fine to let the gradient be zero might be ok when using G-IOU or D-IOU.

In your case, backpropagation still works.
I think you meant this situation: w and h is the width and height of the intersection part. Because we want to maximize the IoU, we must use  - S instead of S as a loss function (because people always minimize the loss function).
The gradient w.r.t w is
g = d(loss)/dw = -dS/dw = -5
If we use SGD to update w. We do:
w = w - g * lr = 0 + 5 * lr
As you can see, the the value of w is now greater than zero as long as the learning rate is positive. Thus, the two boxes have intersection after this update, which is what we want.

For IoU calculation, the two boxes have three kinds of relationships.
a) with the intersection. Both edges of the intersection area are non-zero. Backprop works. (left in the figure)
b) without intersection. Both edges are zero. Backprop doesn't work. (right in the figure)
c) the transition between a) and b) (middle in the figure)
The example you gave is actually the last relationship: the area is zero, but one edge of the intersection is still non-zero. In such case, backpropagation still works.

Thanks for detailed explanation!!! I understood.