Solution servers survive when submitted server doesn't start/respond

Related to #22
After enjoying this great workshop, I noticed that solution servers are still alive.
$ ps ax | grep node
  154   ??  S      0:00.76 /Users/shuhei/.nvm/versions/node/v0.12.0/bin/node /Users/shuhei/.nvm/versions/node/v0.12.0/lib/node_modules/learnyoureact/exercises/props_from_server/solution/solution.js 51137 Bread 14:00
  165   ??  S      0:00.74 /Users/shuhei/.nvm/versions/node/v0.12.0/bin/node /Users/shuhei/.nvm/versions/node/v0.12.0/lib/node_modules/learnyoureact/exercises/props_from_server/solution/solution.js 45928 Milk 13:00
  174   ??  S      0:00.70 /Users/shuhei/.nvm/versions/node/v0.12.0/bin/node /Users/shuhei/.nvm/versions/node/v0.12.0/lib/node_modules/learnyoureact/exercises/props_from_server/solution/solution.js 46569 Car 15:00
...

It seems like solution server survives when the command doesn't connect to submitted server. You can reproduce the phenomenon with the following steps:

Create an empty program.js
learnyoureact and choose an exercise.
learnyoureact verify program.js
ps ax | grep node

I'm still not sure if this is an issue of this repo or workshopper modules though.

I think it's general in workshopper.
Expressworks has explain of this problem

Run $ killall node  before verifying exercises (in your terminal on Mac OS X) to end any previous processes. For Windows, use taskkill /IM node.exe.

Thanks! Closing.


Move to using git subtree

Same as #51 but does not use --squash. One should be closed in favour of the other.
Add a git subtree, I could not get the git subtree add command to use a commit hash so I used a tag - this led me to using v0.19.2 instead of the commit hash we are currently on (six commits after tag v0.19.0).
Includes docs in the README and a version bump so this can be merged and release directly if so desired.
Question
Do we want to release a 0.19.2 version or should we just jump straight to 20.2?
Bah, 10,000 commits - I did not notice that. I think we need to sqaush.

I'll think about the other points when next week (saturday hacking session right now)

Can you use --prefix=depend/bitcoin so that Bitcoin will remain in the same directory? I think you'll also need to add this option to the git submodule pull command.

I tried this at first but then we cannot keep every commit building (because one commit has to remove the current depend/bitcoin then the next commit is the one made by git add subtree? If this is important I can have another play with it.

For me no existing commits compile, so I wouldn't be heartbroken if one more didn't :).
One possible workaround woulrd be to first rename the submodule, then add the subtree and cut over to it, then delete the submodule, all in different commits.

Once I clobbered the bitcoin/depend directory it took me a while to work out how to get it back, this works git submodule update --init --recursive (note the --init).

Leaving this for another day.

I did as you suggested and used a midway tmp submodule. Don't know what the fuss was about yesterday, only took a little while to do :)
I removed the use of --squash as well.

Thanks! Will review this later today or tomorrow.
Curious if anybody else here has an opposition to our use of non-squashed subtrees? This does increase the repo size by several dozen times :)

Curious if anybody else here has an opposition to our use of non-squashed subtrees? This does increase the repo size by several dozen times :)

Don't hold your breath for an answer, not many people watch this crate :)
There is another problem with not squashing. Now running git log --patch @~~.. hangs while git chokes on the size of the patch. That is going to be surprising if people are trying to read patches from arbitrary places before this. I can't remember exactly what it was like with --squash but I can try it again and see.

I don't know about the size differences, from within rust-bitcoinconsensus running du ., du depend, and du .git all return the same number of Megabytes for this and #51 (with --squash).
The git log --patch issue does not exist for #51 though.

The size of depend won't change between the two versions, of course, and your .git directory also won't change in size once you've fetched all the bitcoin commits, unless you entirely re-clone the repo (or somehow convince git to drop the old commits).
I don't understand your comment about git log --patch. What does @~~.. mean?

I don't understand your comment about git log --patch. What does @~~.. mean?

@ is short for HEAD so @~~ is the last two patches back from HEAD and .. to make it a revision-range.

Closing in favour of #51


Peek feature feed back

Description of the new feature / enhancement
The peak function should work with just clicking space bar, Similar to quicklook application and also when selection of next or diffrent file is made it automatically preview the new file just same as quicklook feature
Scenario when this would be used?
Almost everytime to preview a pdf, image and video, specially images, opening in image viewer takes time so power toys peek is the best feature
Supporting information
No response

Tracker for spacebar is #26143


Proof of concept packageSettings with deferredModule

Closing per https://github.com/srid/haskell-flake/pull/87#issuecomment-1450286992


How/why is id="uuid" for Camtrap DP

First reported here
I noticed id is assigned (e.g. with fb2fb39c-3a11-437c-8e60-aa50c5e5172b). How is this value assigned?

Thanks Peter
I answered it there a while ago https://github.com/gbif/ipt/issues/1829#issuecomment-1485135651

My mistake. That should work.


[Concurrency] Fix too optimistic TaskGroup bail-out-when-empty,

discarding group may need to emit an error out of such waitAll attempt, if a previous error was already stored.
The exact dance is:

we store an error from child task
the pending task count is 0
the code trying to waitAll would check status ONLY and bail out, noticing that pending count is zero -- returning the actual body value

Instead, it should:

check again the readyQueue if we're in, if there was a stored value, because if so, it may be an RawError that the DiscardingTaskGroup should emit.

This also is now able to easily handle the "first error always wins" but we choose to implement the "error thrown by body wins" after discussions within the team.
Resolves rdar://104198700
Resolves https://github.com/apple/swift/issues/63147
Resolves rdar://104507347
And also resolves rdar://104212282

This resolves a flaky test (and an actual bug) that @shahmishal and @beccadax reported today.
Thank you for the ping, was a real omission in the code.

@swift-ci please smoke test

I'll have another look and add more tests about the retain/release correctness of the errors... I have a suspicion it might be wrong and over-retain the error a bit... 🤔

Had another bug hiding, we must offerError WHILE holding the group locks ofc, otherwise we get interleaving between the offer and completions of other tasks and may end up returning a success while we intended to throw the body error.
Fix: https://github.com/apple/swift/pull/63016/commits/95628b1094eca626300a10b364963dd7f39968e7

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test linux

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test and merge

@swift-ci please smoke test

All passed but I want to make double-sure here, run again.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test
@swift-ci please smoke test

@swift-ci please smoke test linux

Heh, only remaining thing is a pure virtual method called happening only on linux that I can't explain :-( Getting a linux box to dig deeper.

@swift-ci please smoke test

Managed to reproduce with debug output:
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:847][group(0x559fad1a15f0)] (swift_taskGroup_initializeWithFlagsImpl) create group; flags: isDiscardingResults=1
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:631][group(0x559fad1a15f0,discardResults)] (statusAddPendingTaskRelaxed) addPending, after = TaskGroupStatus{ C:n W:n P:1<PHONE_NUMBER>000000000000000000000000000000000000000000000000000001 }
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:631][group(0x559fad1a15f0,discardResults)] (statusAddPendingTaskRelaxed) addPending, after = TaskGroupStatus{ C:n W:n P:2<PHONE_NUMBER>000000000000000000000000000000000000000000000000000010 }
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1728][group(0x559fad1a15f0,discardResults)] (waitAll) waitAll, bodyError = (nil), status = TaskGroupStatus{ C:n W:n P:2<PHONE_NUMBER>000000000000000000000000000000000000000000000000000010 }
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1743][group(0x559fad1a15f0,discardResults)] (waitAll) waitAll, status = TaskGroupStatus{ C:n W:n P:2<PHONE_NUMBER>000000000000000000000000000000000000000000000000000010 }
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1792][group(0x559fad1a15f0,discardResults)] (waitAll) WATCH OUT, set waiter onto... waitQueue.head = (nil)
[0x7f032a0a9640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1799][group(0x559fad1a15f0,discardResults)] (waitAll) waitAll, marked waiting status = TaskGroupStatus{ C:n W:y P:2<PHONE_NUMBER>000000000000000000000000000000000000000000000000000010 }
[0x7f032b8ac640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1159][group(0x559fad1a15f0,discardResults)] (offer) offer, completedTask:0x7f031c00ed00, error:0, status:TaskGroupStatus{ C:n W:y P:2<PHONE_NUMBER>000000000000000000000000000000000000000000000000000010 }
[0x7f032b8ac640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1167][group(0x559fad1a15f0,discardResults)] (offer) offer, complete, status afterComplete:TaskGroupStatus{ C:n W:y P:1<PHONE_NUMBER>000000000000000000000000000000000000000000000000000001 }
[0x7f032a8aa640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1159][group(0x559fad1a15f0,discardResults)] (offer) offer, completedTask:0x7f031c00e820, error:1, status:TaskGroupStatus{ C:n W:y P:1<PHONE_NUMBER>000000000000000000000000000000000000000000000000000001 }
[0x7f032a8aa640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1167][group(0x559fad1a15f0,discardResults)] (offer) offer, complete, status afterComplete:TaskGroupStatus{ C:n W:y P:0<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000 }
[0x7f032a8aa640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1256][group(0x559fad1a15f0,discardResults)] (resumeWaitingTask) resume waiting task = 0x559fad1a1290, alreadyDecremented:1, error:1, complete with = 0x7f031c00e820
[0x7f032a8aa640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1259][group(0x559fad1a15f0,discardResults)] (resumeWaitingTask) resumeWaitingTask, attempt CAS, waiting task = 0x559fad1a1290, waitQueue.head = 0x559fad1a1290, error:1, complete with = 0x7f031c00e820
[0x7f032a8aa640] [/home/ktoso/swift-project/swift/stdlib/public/Concurrency/TaskGroup.cpp:1296][group(0x559fad1a15f0,discardResults)] (resumeWaitingTask) resume waiting DONE, task = 0x559fad1a1290, backup = 0x559fad1a1290, complete with = 0x7f031c00e820, status = TaskGroupStatus{ C:y W:y P:0<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000 }
main/async_taskgroup_discarding.swift:56: Fatal error: (iteration:33) expected error to be re-thrown, got: 12
Current stack trace:
0    libswiftCore.so                    0x00007f032c5df890 _swift_stdlib_reportFatalErrorInFile + 112
1    libswiftCore.so                    0x00007f032c1d3892 <unavailable> + 1517714
2    libswiftCore.so                    0x00007f032c1d36e6 <unavailable> + 1517286

I can't understand how that's possible; we never hit any "store the result" codepath in the first offer, so how does the 12 end up in the result...

preset=asan
@swift-ci Please test with preset macOS

preset=asan
@swift-ci Please smoke test linux

@swift-ci Please smoke macOS

@swift-ci Please smoke test macOS

Seems linux is passing with the latest rework of waitAll body -- avoiding a race on context mutation. Let's give it another spin though.

@swift-ci Please smoke test linux

@swift-ci Please smoke test linux

@swift-ci Please smoke test

Unlocking one more test
@swift-ci Please smoke test

Also picked over the overflow protection we did way back then in https://github.com/apple/swift/pull/62271
I believe we're finally golden here, let's give it another test run and I'll pick forward.

@swift-ci Please smoke test windows

@swift-ci Please smoke test

@swift-ci please test

ARM_ARCH_7K compilation fun, fixed now.

@swift-ci please test

@swift-ci please smoke test windows


Fix Issue #235

The current implementation of the ApplePayButton only sets the payment items on create.
Changing the payment items after the button is created doesn't change the callback from onPressed.
The example has been updated with quantity, this will show why this PR is needed.
Before:
https://github.com/google-pay/flutter-plugin/assets/75931499/760d4083-f28f-4cff-975b-53a66b3dfb8b
After:
https://github.com/google-pay/flutter-plugin/assets/75931499/051e8ba2-23da-4086-bab0-a389266e3daf

@JlUgia
could you please take a look at this when you get a change, it's a pretty significant bug

We'll also need to merge the conflicts before submitting this.
Let me know if you need any help with that.

Rebased on main, and removed changes from the example app.
Also changed the fix to just use a stateful widget.
Thanks

Thank you @dickermoshe.
Merging.


refactor(protocol): further optimize unnecessary storage writes in proveBlock

@davidtaikocha lets first test this in Hekla.

Looks okay, but there's a lot of logic related to these state transitions and it's too much for me to keep in my head just reviewing these PRs without going through all the logic again so I don't know for sure.

Don't worry, we need to test this PR in hekla to make sure it truly works.

Looks okay, but there's a lot of logic related to these state transitions and it's too much for me to keep in my head just reviewing these PRs without going through all the logic again so I don't know for sure.

Brecht, please take another look. I made some new changes.


https://jsonapi.org/schema#/definitions/failure 404 error

We have used the https://jsonapi.org/schema#/definitions/failure as our API swagger schema ref.
But it looks like recently, https://jsonapi.org/schema has been removed? It  return 404 error now?
Questions:

Should we use the https://jsonapi.org/schema as the schema content ref? any replacement?
What was the content inside https://jsonapi.org/schema before?
What's the best practice?

Having just begun my JSON:API journey, it was a bummer to find the schema missing. It is still referenced at https://jsonapi.com/faq :

@jelhan would you mind looking into the issue, please?

@hipages-guoxu

What was the content inside https://jsonapi.org/schema before?

The file was deleted in af47518badf387775184872680b7f6fb4763ecda , its last content can be reviewed here

I help maintain SchemaStore/schemastore and noticed this too - https://jsonapi.org/schema 404's. It would be good to fix this or make the schemas publicly referencable somehow. Currently I'm pruning unreachable entries from our schema catalog, and this one is one of those.
Seems related to #1749 #1672


NPE in serveDevTools

This happened with run -d chrome on Windows with the latest dev branch 1.10.15. The issue might be in devtools @DaveShuckerow or in dwds handling of devtools @grouma
NoSuchMethodError: The method 'toFilePath' was called on null.
Receiver: null
Tried calling: toFilePath()

  | at Object.noSuchMethod | (object_patch.dart:51 )
-- | -- | --
  | at defaultHandler | (handlers.dart:28 )
  | at <asynchronous gap> | (async )
  | at serveDevTools | (server.dart:143 )
  | at <asynchronous gap> | (async )
  | at DevTools.start | (devtools.dart:27 )
  | at <asynchronous gap> | (async )
  | at Dwds.start | (dwds.dart:99 )
  | at <asynchronous gap> | (async )
  | at WebFs.start | (web_fs.dart:287 )
  | at <asynchronous gap> | (async )
  | at ResidentWebRunner.run.<anonymous closure> | (resident_web_runner.dart:184 )
  | at <asynchronous gap> | (async )
  | at asyncGuard.<anonymous closure> | (async_guard.dart:111 )
  | at <asynchronous gap> | (async )
  | at _rootRun | (zone.dart:1124 )
  | at _CustomZone.run | (zone.dart:1021 )
  | at _runZoned | (zone.dart:1516 )
  | at runZoned | (zone.dart:1500 )
  | at asyncGuard | (async_guard.dart:109 )
  | at ResidentWebRunner.run | (resident_web_runner.dart:183 )
  | at <asynchronous gap> | (async )
  | at RunCommand.runCommand | (run.dart:494 )
  | at <asynchronous gap> | (async )
  | at FlutterCommand.verifyThenRunCommand | (flutter_command.dart:557 )
  | at _asyncThenWrapperHelper.<anonymous closure> | (async_patch.dart:71 )
  | at _rootRunUnary | (zone.dart:1132 )
  | at _CustomZone.runUnary | (zone.dart:1029 )
  | at _FutureListener.handleValue | (future_impl.dart:137 )
  | at Future._propagateToListeners.handleValueCallback | (future_impl.dart:678 )
  | at Future._propagateToListeners | (future_impl.dart:707 )
  | at Future._completeWithValue | (future_impl.dart:522 )
  | at _AsyncAwaitCompleter.complete | (async_patch.dart:30 )
  | at _completeOnAsyncReturn | (async_patch.dart:288 )
  | at RunCommand.usageValues | (run.dart )
  | at _asyncThenWrapperHelper.<anonymous closure> | (async_patch.dart:71 )
  | at _rootRunUnary | (zone.dart:1132 )
  | at _CustomZone.runUnary | (zone.dart:1029 )
  | at _FutureListener.handleValue | (future_impl.dart:137 )
  | at Future._propagateToListeners.handleValueCallback | (future_impl.dart:678 )
  | at Future._propagateToListeners | (future_impl.dart:707 )
  | at Future._completeWithValue | (future_impl.dart:522 )
  | at _AsyncAwaitCompleter.complete | (async_patch.dart:30 )
  | at _completeOnAsyncReturn | (async_patch.dart:288 )
  | at IosProject.isSwift | (project.dart )
  | at _asyncThenWrapperHelper.<anonymous closure> | (async_patch.dart:71 )
  | at _rootRunUnary | (zone.dart:1132 )
  | at _CustomZone.runUnary | (zone.dart:1029 )
  | at _FutureListener.handleValue | (future_impl.dart:137 )
  | at Future._propagateToListeners.handleValueCallback | (future_impl.dart:678 )
  | at Future._propagateToListeners | (future_impl.dart:707 )
  | at Future._completeWithValue | (future_impl.dart:522 )
  | at Future._asyncComplete.<anonymous closure> | (future_impl.dart:552 )
  | at _rootRun | (zone.dart:1124 )
  | at _CustomZone.run | (zone.dart:1021 )
  | at _CustomZone.runGuarded | (zone.dart:923 )
  | at _CustomZone.bindCallbackGuarded.<anonymous closure> | (zone.dart:963 )
  | at _microtaskLoop | (schedule_microtask.dart:41 )
  | at _startMicrotaskLoop | (schedule_microtask.dart:50 )
  | at _runPendingImmediateCallback | (isolate_patch.dart:116 )
  | at _RawReceivePortImpl._handleMessage | (isolate_patch.dart:173 )

The only place we call that in package:dwds is here:
https://github.com/dart-lang/webdev/blob/master/dwds/lib/src/handlers/injected_handler.dart#L35
For the null issue to happen, package:dwds would not be able to read the injected client file which would be extremely weird given that it ships with the package.

I wonder if that returns null if the Isolate.resolvePackageUri fails? IIRC there were some issues with something similar that I hacked around a while back. I'll see if I can repro again

have similar issue when I run "flutter run -d web-server".
flutter --verison

Flutter 1.12.1 • channel dev • https://github.com/flutter/flutter.git
Framework • revision 86c91b12d8 (4 days ago) • 2019-11-11 13:29:46 -0800
Engine • revision 31cd2dfca2
Tools • Dart 2.7.0

Flutter crash report; please file at https://github.com/flutter/flutter/issues.

command
flutter run -d web-server
exception
NoSuchMethodError: NoSuchMethodError: The method 'toFilePath' was called on null.

Have similar issues when executing "flutter run -d web-server" in the docker environment (flutter dev v1.12.1). However when I rerun the same command, it works. I've tried several times already. Pretty strange.

odoo13@master-node:~/docker/dart_flutter_web$ sudo docker run -p 8443:8443 -p 8080:8080 -it flutter bash
root@56bffc611146:/works/dweb# flutter run -d web-server
Downloading Web SDK...                                              0.5s
Launching lib/main.dart on Web Server in debug mode...
Building application for the web...                                13.3s

Sending crash report to Google.
Crash report sent (report ID: 6676d4e0ac21fce0)
Oops; flutter has exited unexpectedly.
Crash report written to /works/dweb/flutter_01.log;
please let us know at https://github.com/flutter/flutter/issues.
root@56bffc611146:/works/dweb# flutter run -d web-server
Launching lib/main.dart on Web Server in debug mode...
Building application for the web...                                35.7s
lib/main.dart is being served at http://localhost:44537/
Warning: Flutter's support for web development is not stable yet and hasn't
been thoroughly tested in production environments.
For more information see https://flutter.dev/web
🔥  To hot restart changes while running, press "r". To hot restart (and refresh the browser), press "R".
For a more detailed help message, press "h". To quit, press "q".

Having a similar issue with flutter run -d Chrome
Launching lib/main.dart on Chrome in debug mode...
Unhandled exception:
NoSuchMethodError: The method '[]' was called on null.
Receiver: null
Tried calling: []("packages")
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:53:5)
#1      _parseDependencyTypes
(package:build_runner_core/src/package_graph/package_graph.dart:194:41)
#2      new PackageGraph.forPath
(package:build_runner_core/src/package_graph/package_graph.dart:70:29)
#3      new PackageGraph.forThisPackage
(package:build_runner_core/src/package_graph/package_graph.dart:98:57)
#4      new BuildCommandRunner (package:build_runner/src/entrypoint/runner.dart:27:37)
#5      run (package:build_runner/src/entrypoint/run.dart:22:16)
#6      main (package:flutter_tools/src/build_runner/build_script.dart:181:28)
#7      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:303:32)
#8      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:174:12)
Building application for the web...                                12.7s
Failed to start build daemon. The process might have exited unexpectedly during startup.
Try running the application again.

@jonahwilliams what's the status here? Can we close?

I haven't seen this in forever, we can close it

I am running into this on 1.20.0-7.2.pre when target web from this machine for the first time.
From freshly created app:
➜  myapp flutter run -d chrome
Launching lib/main.dart on Chrome in debug mode...
Syncing files to device Chrome...
11,001ms (!)
ERROR - 2020-07-21 16:25:49.135748
GET /dwds/src/injected/client.js
Error thrown by handler.
NoSuchMethodError: The method 'toFilePath' was called on null.
Receiver: null
Tried calling: toFilePath()
dart:core                                      Object.noSuchMethod
package:dwds/src/handlers/injector.dart 51:41  DwdsInjector.middleware.<fn>.<fn>

➜  temp flutter upgrade
Flutter is already up to date on channel beta
Flutter 1.20.0-7.2.pre • channel beta • https://github.com/flutter/flutter.git
Framework • revision a2bde82fbd (3 days ago) • 2020-07-18 15:16:35 -0700
Engine • revision 60b269d898
Tools • Dart 2.9.0 (build 2.9.0-21.2.beta)

➜  temp flutter config --enable-web
Setting "enable-web" value to "true".
You may need to restart any open editors for them to read new settings.

➜  temp flutter devices
2 connected devices:

Web Server (web) • web-server • web-javascript • Flutter Tools
Chrome (web)     • chrome     • web-javascript • Google Chrome 84.0.4147.89

➜  temp flutter create myapp
Creating project myapp...
  myapp/ios/Runner.xcworkspace/contents.xcworkspacedata (created)
  myapp/ios/Runner.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist (created)
  myapp/ios/Runner.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings (created)
  myapp/ios/Runner/Info.plist (created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
  myapp/ios/Runner/Assets.xcassets/LaunchImage.imageset/README.md (created)
  myapp/ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json (created)
  myapp/ios/Runner/Assets.xcassets/LaunchImage.imageset/LaunchImage.png (created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
  myapp/ios/Runner/Assets.xcassets/AppIcon.appiconset/Contents.json (created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
<EMAIL_ADDRESS>(created)
  myapp/ios/Runner/Base.lproj/LaunchScreen.storyboard (created)
  myapp/ios/Runner/Base.lproj/Main.storyboard (created)
  myapp/ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata (created)
  myapp/ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist (created)
  myapp/ios/Runner.xcodeproj/project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings (created)
  myapp/ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme (created)
  myapp/ios/Flutter/Debug.xcconfig (created)
  myapp/ios/Flutter/Release.xcconfig (created)
  myapp/ios/Flutter/AppFrameworkInfo.plist (created)
  myapp/ios/.gitignore (created)
  myapp/test/widget_test.dart (created)
  myapp/myapp.iml (created)
  myapp/.gitignore (created)
  myapp/web/favicon.png (created)
  myapp/web/index.html (created)
  myapp/web/manifest.json (created)
  myapp/web/icons/Icon-192.png (created)
  myapp/web/icons/Icon-512.png (created)
  myapp/.metadata (created)
  myapp/android/app/src/profile/AndroidManifest.xml (created)
  myapp/android/app/src/main/res/mipmap-mdpi/ic_launcher.png (created)
  myapp/android/app/src/main/res/mipmap-hdpi/ic_launcher.png (created)
  myapp/android/app/src/main/res/drawable/launch_background.xml (created)
  myapp/android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png (created)
  myapp/android/app/src/main/res/mipmap-xxhdpi/ic_launcher.png (created)
  myapp/android/app/src/main/res/values/styles.xml (created)
  myapp/android/app/src/main/res/mipmap-xhdpi/ic_launcher.png (created)
  myapp/android/app/src/main/AndroidManifest.xml (created)
  myapp/android/app/src/debug/AndroidManifest.xml (created)
  myapp/android/gradle/wrapper/gradle-wrapper.properties (created)
  myapp/android/gradle.properties (created)
  myapp/android/.gitignore (created)
  myapp/android/settings.gradle (created)
  myapp/android/app/build.gradle (created)
  myapp/android/app/src/main/kotlin/com/example/myapp/MainActivity.kt (created)
  myapp/android/build.gradle (created)
  myapp/android/myapp_android.iml (created)
  myapp/pubspec.yaml (created)
  myapp/README.md (created)
  myapp/ios/Runner/Runner-Bridging-Header.h (created)
  myapp/ios/Runner/AppDelegate.swift (created)
  myapp/ios/Runner.xcodeproj/project.pbxproj (created)
  myapp/lib/main.dart (created)
  myapp/.idea/runConfigurations/main_dart.xml (created)
  myapp/.idea/libraries/Dart_SDK.xml (created)
  myapp/.idea/libraries/KotlinJavaRuntime.xml (created)
  myapp/.idea/modules.xml (created)
  myapp/.idea/workspace.xml (created)
Running "flutter pub get" in myapp...                                  1.2s
Wrote 76 files.

All done!
myapp
[✓] Flutter: is fully installed. (Channel beta, 1.20.0-7.2.pre, on Mac OS X 10.15.2 19C57, locale en-US)
[!] Android toolchain - develop for Android devices: is partially installed; more components are available. (Android SDK
    version 30.0.0)
[✓] Xcode - develop for iOS and macOS: is fully installed. (Xcode 11.4)
[✓] Chrome - develop for the web: is fully installed.
[✓] Android Studio: is fully installed. (version 4.0)
[!] IntelliJ IDEA Ultimate Edition: is partially installed; more components are available. (version 2020.1.3)
[✓] Connected device: is fully installed. (2 available)

➜  temp cd myapp
➜  myapp flutter run -d chrome
Launching lib/main.dart on Chrome in debug mode...
Syncing files to device Chrome...
11,001ms (!)
ERROR - 2020-07-21 16:25:49.135748
GET /dwds/src/injected/client.js
Error thrown by handler.
NoSuchMethodError: The method 'toFilePath' was called on null.
Receiver: null
Tried calling: toFilePath()
dart:core                                      Object.noSuchMethod
package:dwds/src/handlers/injector.dart 51:41  DwdsInjector.middleware.<fn>.<fn>

This implies the prebuilt client.js isn't resolved here.
I'm not sure why the package resolver would not be able to load that file if package:dwds is a dependency of Flutter Tools. @jonahwilliams thoughts?

Update: I tried it out on dev,  1.21.0-1.0.pre, and it worked. Now when I switch back to beta, beta works. Beta also now works from a fresh project.
If I then delete the flutter install, and re-install on beta, beta is broken again.  So building from dev cached something in the flutter dir to make it happy.
Flutter 1.21.0-1.0.pre • channel dev • https://github.com/flutter/flutter.git
Framework • revision f25bd9c55c (7 days ago) • 2020-07-14 20:26:01 -0400
Engine • revision 99c2b3a245
Tools • Dart 2.9.0 (build 2.9.0-21.0.dev 20bf2fcf56)

I had same issue on new project not working on web... Even added dwds package not solved anyone know anything???
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel dev, 1.21.0-1.0.pre, on Microsoft Windows [Version 10.0.18363.959], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Chrome - develop for the web
[√] Android Studio (version 4.0)
[√] VS Code (version 1.47.3)
[√] Connected device (4 available)
Launching lib\main.dart on Chrome in debug mode...
ERROR - 2020-08-08 06:49:05.954007
GET /dwds/src/injected/client.js
Error thrown by handler.
NoSuchMethodError: The method 'toFilePath' was called on null.
Receiver: null
Tried calling: toFilePath()
dart:core                                      Object.noSuchMethod
DwdsInjector.middleware..
package:dwds/…/handlers/injector.dart:51

I had same issue on new project not working on web... Even added dwds package not solved anyone know anything???
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel dev, 1.21.0-1.0.pre, on Microsoft Windows [Version 10.0.18363.959], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Chrome - develop for the web
[√] Android Studio (version 4.0)
[√] VS Code (version 1.47.3)
[√] Connected device (4 available)
Launching lib\main.dart on Chrome in debug mode...
ERROR - 2020-08-08 06:49:05.954007
GET /dwds/src/injected/client.js
Error thrown by handler.
NoSuchMethodError: The method 'toFilePath' was called on null.
Receiver: null
Tried calling: toFilePath()
dart:core Object.noSuchMethod
DwdsInjector.middleware..
package:dwds/…/handlers/injector.dart:51

ok flutter packages-update solved it

@jonahwilliams It seems like the recent comments here and https://github.com/flutter/flutter/issues/58110, https://github.com/flutter/flutter/issues/58944, and https://github.com/flutter/flutter/issues/63896 (Aug 16) warrant opening this up again.
All of these are getting an error with client.js after upgrading/enabling.
GET /dwds/src/injected/client.js
Error thrown by handler.
NoSuchMethodError: The method 'toFilePath' was called on null.
Receiver: null
Tried calling: toFilePath()
dart:core                                              Object.noSuchMethod
package:dwds/src/handlers/injected_handler.dart 35:39  createInjectedHandler.<fn>.<fn>

It was happening to me previously, then I added   dwds: ^7.1.1 to my dependencies and it resolved. now its back.


Can't install specified version of GBDeviceInfo with Cocoapods

Here is content of my Podfile:
platform :ios, '6.0'
pod 'GBDeviceInfo', '~> 3.5'
pod 'GBDeviceInfo/Jailbreak', '~> 3.5'

But after executing pod install, it responsed this:

Neither the search results contain the specified version 3.5, as you can see in this snapshot above.

Strange. Can you try 3.6?

Confirm. Also dragging manually to the swift project not working. Have multiple errors like "CGFloat not found".

@lmirosevic , I tried, but still didn't work, generating the same error.


Missing @change event

Hi, looks like on change event doesn't exist,
event thougt we can use v-model

You're right, I'm not a fan of adding these kind of events as most of the time, they are used incorrectly and cause side-effects.
Also, this can be easily achieved using a watch on the v-model value, but I agree this isn't convenient.
What would be the use case of this @change event for you?

oh okay, I found it, i could use @option-selected on my case,
thank you


Ability to run build scripts before docker builds

Describe the solution you'd like

This could be in the project definition (nitric.yaml)
buildScripts:
 - yarn install

Why is this needed? What challenge will it help you solve? Please describe.

There are often commands needed to be run before a docker build, it would be great to have a mechanism
to say "please run this command before doing the docker build"
Describe alternatives you've considered

We have to run this manually and document it.

This requires a conversation before we have anything to action.

Options include exposing a docker file which can be edited
Consider hot-reloading
Might need a convention which can be overwritten

Keeping the docker file hidden with defaults should also be available.

Will be implemented as part of defining custom docker files


Bump version: 2.6.0 → 2.6.1: Fix regex character class inversion

Argh, sorry for the regex bug! Shouldn't have rushed.

No worries, I think I actually got the suggestion wrong :).


Now when I'm using the latest google_sign_in_android: ^6.1.13

          Now when I'm using the latest google_sign_in_android: ^6.1.13

Unble to sync the native Android project.
getting following errors.
1: Task failed with an exception.
-----------
* Where:
Build file '/Users/mohmedsafvankp/.pub-cache/hosted/pub.dev/google_sign_in_android-6.1.13/android/build.gradle' line: 24

* What went wrong:
A problem occurred evaluating project ':google_sign_in_android'.
> No signature of method: build_n3eadu0qz7ey661tsmy5sjq1.android() is applicable for argument types: (build_n3eadu0qz7ey661tsmy5sjq1$_run_closure2) values: [build_n3eadu0qz7ey661tsmy5sjq1$_run_closure2@73fd87a2]

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

* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating project ':google_sign_in_android'.
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93)
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.lambda$apply$0(DefaultScriptPluginFactory.java:133)

and
Task failed with an exception.
-----------
* Where:
Script '/Users/mohmedsafvankp/flutter_sdk/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 463

* What went wrong:
A problem occurred configuring project ':google_sign_in_android'.
> Cannot invoke method substring() on null object

Originally posted by @MohamedSafvanKP-MSIL in https://github.com/flutter/flutter/issues/125482#issuecomment-1524683735

I also encounter this problem when I updated a package and my app doesn't run anymore.

i have the same problem

Hi @MohamedSafvanKP-MSIL, please share the content of the following files

android/build.gradle
android/gradle/wrapper/gradle-wrapper.properties

Please also provide the output of flutter doctor -v.
Thank you

hi @danagbemava-nc
In build.gradle
compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

and
dependencies {
        classpath 'com.android.tools.build:gradle:4.1.1'

In android/gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-6.5-all.zip

note: Above is my native Android project setups.
Here I'm using Flutter as a module for my existing native application.
No issues facing while running modules alone.
But I'm facing then above issues only when I'm running the native application which is integrated with the Flutter module.

flutter doctor -v

[✓] Flutter (Channel stable, 3.7.8, on macOS 13.2 22D49 darwin-arm64, locale en-IN)
    • Flutter version 3.7.8 on channel stable at /Users/mohmedsafvankp/flutter_sdk/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 90c64ed42b (5 weeks ago), 2023-03-21 11:27:08 -0500
    • Engine revision 9aa7816315
    • Dart version 2.19.5
    • DevTools version 2.20.1

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    • Android SDK at /Users/mohmedsafvankp/Library/Android/sdk
    • Platform android-33, build-tools 33.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14C18
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-8887301)

[✓] IntelliJ IDEA Community Edition (version 2023.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.76.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.60.0

[✓] Connected device (3 available)
    • POCO M2 Pro (mobile) • <IP_ADDRESS>:5555 • android-arm64  • Android 13 (API 33)
    • macOS (desktop)      • macos              • darwin-arm64   • macOS 13.2 22D49 darwin-arm64
    • Chrome (web)         • chrome             • web-javascript • Google Chrome 112.0.5615.137

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

solved by doing
flutter clean
flutter pub upgrade

and updating gradles
in android/build.gradle
    ext.kotlin_version = '1.7.10'
...

dependencies {
        classpath 'com.android.tools.build:gradle:7.2.0'
        ...

in android /gradle/wrapper
distributionUrl=https\://services.gradle.org/distributions/gradle-7.5-all.zip

and finally in android/app/build.gradle
   buildTypes {
        release {

            signingConfig signingConfigs.release
             //   useProguard true -------> remove this
            shrinkResources true. -------> add this
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

        }

hope it solve the issue

Upgrading AGP requires a lot of adaptation work

try limit all name start with io.io.flutter.plugins.xxxxx version number to use the previous version in pubspec.yaml, can fix it~

This an unexpected regression due to adding AGP 8.0 compatibility; https://github.com/flutter/flutter/issues/125621 tracks reverting the change; I expect that to happen later today.


Results should have add method

We want to be able to combine Results objects into a Results object, eg, because scenarios were run in batches.
Currently, adding Results objects creates a list that does not have Results methods available to it:
from edsl.questions import QuestionFreeText
from edsl import Scenario, Survey

texts = ["text 1", "text 2", "text 3", "text 4", "text 5", "text 6", "text 7", "text 8", "text 9" "text 10"]

q = QuestionFreeText(
    question_name = "example",
    question_text = "What is the number in this text: {{ text }}"
)

survey = Survey([q])

scenarios = [Scenario({"text":t}) for t in texts]

def chunked_iterable(iterable, size):
    for i in range(0, len(iterable), size):
        yield iterable[i:i + size]

all_results = []

for batch in chunked_iterable(scenarios, 10):
    results = survey.by(batch).run()
    all_results.append(results)

# Results methods are not available eg:
all_results.columns
all_results.show_exceptions()

Thanks - I can understand why show_exceptions doesn't work---what does all_results.columns return? That one seems like it should just work...

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[10], line 2
      1 # Results methods are not available eg:
----> 2 results_list.columns
      3 # results_list.show_exceptions()

AttributeError: 'list' object has no attribute 'columns'


Add link to TextMate 2 bundle

Awesome! Thanks for making this :D

My pleasure! Thanks for all the stuff you make. :smile:


Comment

utterances
A lightweight commenting system using GitHub issues.
https://utteranc.es/

a

s

d

abc


C++ Interop: add a test for std module interface

The test checks that the Swift module interface for std & its submodules can be generated & that it contains a couple of known declarations.
This is a follow-up after https://github.com/apple/swift/pull/37806.

@swift-ci please smoke test

Swift Test Linux Platform (smoke test)

Probably best to just disable this test on Linux until we support libstdc++ (very soon). But I don't feel strongly.

Probably best to just disable this test on Linux until we support libstdc++

Agreed, I disabled it on Linux for now.

@swift-ci please smoke test

@swift-ci please test Windows

@swift-ci please smoke test Linux


[Feature Request] deferLoading on DataTables

It's been reported here that on the ListOperation we now have an initial flash of unloaded content, then the loading spinner, then the content loads, which could be improved just by adding deferLoading => false to the DataTables configuration.
It sounds like a good idea if it's that easy to do. The problem is - I don't see an initial flash.  The page loads and the dataTables have black text, then it appears that the page loads a second time, (at least, the inspector html does a full rewrite of the dom), then the table turns white, the loader appears briefly, then the content pops in.
It would be great if there was a way to configure an initial batch of content that php could load serverside, then use deferLoading to avoid the ajax takeover.
My concern is the client noticing the initial changes to the page and thinking it looks "buggy".

Hello @ericjanofski
I can see the "flick" you talk about, we draw the table headers, and then the table enters in a "loading state", making the content "white" while loading.
To use the deferLoading we need to have some data in the initial request to populate the table, that's not how Backpack have it implemented. All the table data is get from the ajax request, so what you see in page first is just an "html" table (headers and stuff), and then datatable initialization script is run. At the time the first paint is made we have no info on what data will be displayed in the table.
One workaround is making the table "appear" the same as it will be when loading starts (whiter) by styling the headers and the text to match the loading state, and when it finish loading remove the "whiter" classes to show the black bold ones!
That way the flick would not be noticeable because they look the same.
@tabacitu you can make Chrome Devtools throttle your connection to be a 3G one and you will see the flick. In high connections the flick is unoticeable.

Best,
Pedro

Thanks Pedro, your response is much appreciated. I believe your proposed solution would be a step in the right direction. In order to attach classes or use a javascript callback would I be using the dataTables config file overwritten here:
/resources/views/render/backpack/crud/inc/datatables_logic.blade.php
or is there another way Backpack hooks into that?
Thank you for your time.

@ericjanofski you can publish the view with: php artisan backpack:publish inc/datatables_logic it will be in your resources/views with vendor path.
If you found a solution that you are happy with and would like to contribute let us know, maybe it's a solution for backpack core, or could help other people that are annoyed by this "flick".
Wish you the best,
Pedro

Closing as non-priority. Happy to discuss if we have a PR.


Work on merge of two libraries

Hey mate, I like the work you're doing with this. My own jvc_projector module was recently updated to support the newer models with passwords. In addition to the develop fork where I was working on (but ran out of time) an async version of the library, I also recently added more robustness and better error checking for the communications protocol in the improved_commands branch.
The rationale for the improved_commands branch is to allow specifying a single structure which will allow the code to execute both read and write type commands for that particular feature. I initially tried to retain the Enum structures as you have, but it was difficult to specify for commands that would be read only or write only. For the current version which I am still testing, I have settled on using the dict based structure.
My plan was actually to get back to work on the async version, but I realised that a little more robustness was needed for the _send_command() method, which is what lead me down this rabbit hole. I'm not sure async is really even a must here, as the control server on the projector is not really async in any way and we can call synchronous functions from homeassistant using:
# hub.update() is a sync function.
result = await hass.async_add_executor_job(hub.update)

Once I've got the commands stuff worked out, I will still work on bringing async into my version.
Would you be willing to work with me on bringing your changes into the library? I'm mostly asking for a bit of support in testing/validation/debugging with your projector. Since you know python and you have one of the projectors, your insight is very valuable.

Hey,
Thank you. The reason I went with Enums is because it made specifying send and receive acks easier and nicer. Async is not necessary per se but its easier to integrate with HA in addition to supporting other front ends. In my quick testing it also was more reliable because it seems to queue commands instead of having them drop off if there are issues, but that might have been unrelated. I am happy to test your changes on my setup, but it might be easier to develop on this library since I am happy with my implementation and its feature complete, IMO. Only thing I want to improve is the reconnect mechanism which is mostly reliable but has edge cases.


Add CLAHE to opencv image tool

Implement Contrast limited adaptive histogram equalization. This is similar to the existing histogram equalization tool but allows for locally boosting contrast.
The implementation is based on the existing histogram equalization, but added input fields for clip limit, tile rows, and tile columns.
Motivation and context

In some of our annotation work I was finding the existing histogram equalization to not brighten some regions significantly.
Resolves #4929

How has this been tested?
Manual testing
Checklist

[x] I submit my changes into the develop branch
[x] I have created a changelog fragment
[x] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[x] I have linked related issues (see GitHub docs)
[ ] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

Summary by CodeRabbit
Release Notes

New Features

Introduced a Contrast Limited Adaptive Histogram Equalization (CLAHE) tool for enhanced image contrast.
Added input fields for adjusting CLAHE parameters (Clip Limit, Tile Rows, Tile Columns) in the OpenCV control panel.

Documentation

Expanded the OpenCV section in the AI tools manual to include detailed explanations of Histogram Equalization and CLAHE.

Hi @denck007 , do you still want to finish this PR?

This PR has been inactive for over three weeks, so I will close it for now. The functionality is excellent, but the code requires some improvements. Please feel free to re-open if you're ready to complete the feature.


Bugfix/command name truncation #1251

Description

Updated the read_command_name function to improve command name handling by using /proc/self/cmdline instead of /proc/self/stat.
Normalizes command names by removing unnecessary parentheses.

Changes

Replaced /proc/self/stat with /proc/self/cmdline in read_command_name.
Added normalization logic to handle edge cases for command names.
Validates:

Normal command names.
Command names with parentheses.
Edge cases like empty or malformed input.
Command line with arguments.

Related Issue
Fixes #1251.
Checklist

[x] Code adheres to Google C++ coding style.
[x] Code is added where appropriate without introducing unrelated changes.

It seems that you have used some tool for automatically formatting the code, which has generated a large number of irrelevant diffs. Could you only submit the necessary code modifications?
In addition, the cmake builds have failed.


Doc updates including new page for troubleshooting

This PR includes a batch of doc updates including:

add new troubleshooting page showing how to capture REST API traffic
rewrite sign in / sign out page to be more clear, in particular server vs online, and to - mention switch_site
dev-guide, index, samples, versions: some general edits and improvements
api-ref: added auth.switch_site (from #655)

Nothing in here is tied to any code changes, so it can be merged into gh-pages when ready. I'll squash all the commits before merging.

These pages are reviewable - one more page coming.

Thanks Chris for the feedback - I squashed and rebased so it can merge as one commit. (And I did a trim all trailing white space on api-ref.md to clean that up.)


Modularize the JavaScript

When served, the compiled app.js is a behemoth 10MB file, which is loaded along with other 25+ assets on the first loading of the website (even before the app to be able to decide whether to show the login page or the blank template page).
This would throttle performance & may end up chocking the application as it grows larger. FWIW, it's just beyond the MVP at this point, and browser already eats processor's soul to process the JS.
We should rather go more modular way of serving JS, depending on the requirement(s) of the current view (and not serving everything we have, up front, 90% of which may be needed or not).

If you use gulp compile --prod, it generates optimized JS with size around 1MB. We should still be able reduce this.
Regarding modules, browserify which is being used currently doesn't support that. We need to move towards webpack/jspm to have this capability.


Add a transaction origination timestamp and expiration TTL

It would be very useful for chainweb if Pact transactions had the following mandatory fields in PublicMeta:

origination (or "creation") timestamp

time-to-live. TTL can be expressed in seconds, and maximum value should be small enough that we can fit it into Word16.

Much of the rest of this note is about how this data will be consumed on the chainweb side.
Validation
For the semantics of the new fields, consider a block B having block timestamp tB and transaction s having origination timestamp tS and TTL dS. The following inequalities must hold for s to validate in block B:

tS < tB  (the transaction cannot be newer than the block)
tS + dS <= tB (the transaction must make it into a block before expiry)
tB > t_{parent(B)}  (block time must be strictly monotonically increasing)

Clock skew / future timestamps
To avoid having to synchronize on timestamp, nodes need to deal with inputs arriving from the future. Let's talk about clock skew for blocks and clock skew for transactions.
Clock skew for blocks
We will choose a maximum block clock skew k. If a node receives a block B having a timestamp more than k seconds in the future, it should be dropped. If the most recent block had a future timestamp (due to skew), it is important that newBlock account for this to maintain block timestamp monotonicity.
Clock skew for pact txs
We will not allow any skew for transactions relative to blocks, i.e. block time is absolute. This means that transaction clock skew has to be handled at the Chainweb Pact RestAPI/mempool level, since this is the component that receives new pact transactions via the /send endpoint.
Transactions arriving at a node with a timestamp that is not "too far" in the future (here we can make maximum clock skew configurable, but O(10 seconds) is probably ok) will be placed into "purgatory" until after the transaction begin time is past. Once the origination time is no longer in the future, the transaction will be released to the regular pending mempool for candidate inclusion into the next mined block.

Thanks @gregorycollins. Assigning to myself, and I can have this out today for Chainweb

tB > t_{parent(B)} (block time must be strictly monotonically increasing)

This is already enforced during block validation.

Clock skew for blocks

Consensus has following rule: If a node sees a block with tB in the future (with respect to the current clock) it is dropped or ignored until it tB is current. There is no formal assumption about clock synchronization. We think, that above rule provides sufficient incentive for nodes to keep their clocks in sync with respect to universal time (SI seconds since unix epoch).

We will choose a maximum block clock skew k

As pointed out above, consensus make no assumptions about clock skew. It just ignores events that happened in the future with respect to the local clock. (If the network link of a node doesn't allow the node to sync its local clock with UT to values sufficiently smaller than the block rate, it won't be able to successfully participate in consensus in any case.)
The current behavior is that validation fails, which is equivalent to dropping the node. There is a long standing Github issue for adding a short-term "staging" cache for blocks that validation due to a temporary condition and may pass in the future.

Thanks @gregorycollins. Assigning to myself, and I can have this out today for Chainweb. How does the following sound for PublicMeta?:
data PublicMeta = PublicMeta
  { _pmChainId :: !ChainId
  , _pmSender :: !Text
  , _pmGasLimit :: !GasLimit
  , _pmGasPrice :: !GasPrice
  , _pmTTL :: !Word16
  , _pmCreationTime :: !Int64
  } deriving (Eq, Show, Generic)

Int64 is a representation of time in Micros, which aligns with our representation in Chainweb.

I would make at least a type alias (probably not a newtype) for both, e.g. type TTLSeconds = Word16 -- usually for timestamps you add a comment indicating the format (e.g. "micros since unix epoch")

The current consensus policy with respect to block times are documented here: https://github.com/kadena-io/chainweb-node/blob/2a9c5ab44f30d2faadbd3b3361cb7d6a8f2aad48/src/Chainweb/BlockHeader.hs#L307

The current behavior is that validation fails, which is equivalent to dropping the node. There is a long standing Github issue for adding a short-term "staging" cache for blocks that validation due to a temporary condition and may pass in the future.

We can get away with being absolute about timestamps for now (especially since our validate processing is slow), but some laxity in allowable clock skew is really desirable for distributed systems.
If a node can generate and send blocks to a remote receiver in time t, and we have clock skew s >= t, we can get into a bizarre situation where nodes can only meaningfully participate on the network with other nodes that are sufficiently far away (where round-trip latency delays things long enough for time to catch up to the "future" blocks the skewed node is sending).

time-to-live. TTL can be expressed in seconds, and maximum value should be small enough that we can fit it into Word16.

My understanding is, that this value may have a big impact on the performance of Chainweb. Assuming a target block rate of 2 blocks per chain per minute, actual per chain block time can range roughly between 0.6 and 6 blocks per minute.
Assuming at most 1000 tx per block, a TTL value of 1 day may span over up to 8,640,000 transactions per chain and 172,800,000 tx for 20 chains. (Ethereum has processed less than 550,000,000 tx since its inception and the highest number of tx ever processed on a single day was 1,349,890.)

time-to-live. TTL can be expressed in seconds, and maximum value should be small enough that we can fit it into Word16.

My understanding is, that this value may have a big impact on the performance of Chainweb. Assuming a target block rate of 2 blocks per chain per minute, actual per chain block time can range roughly between 0.6 and 6 blocks per minute.
Assuming at most 1000 tx per block, a TTL value of 1 day may span over up to 8,640,000 transactions per chain and 172,800,000 tx for 20 chains. (Ethereum has processed less than 550,000,000 tx since its inception and the highest number of tx ever processed on a single day was 1,349,890.)

N.B. Word16 in seconds means maximum TTL would be 18 hours. We have to be able to keep an 18 hour window of transaction hash information online, right?

time-to-live. TTL can be expressed in seconds, and maximum value should be small enough that we can fit it into Word16.

My understanding is, that this value may have a big impact on the performance of Chainweb. Assuming a target block rate of 2 blocks per chain per minute, actual per chain block time can range roughly between 0.6 and 6 blocks per minute.
Assuming at most 1000 tx per block, a TTL value of 1 day may span over up to 8,640,000 transactions per chain and 172,800,000 tx for 20 chains. (Ethereum has processed less than 550,000,000 tx since its inception and the highest number of tx ever processed on a single day was 1,349,890.)

N.B. Word16 in seconds means maximum TTL would be 18 hours. We have to be able to keep an 18 hour window of transaction hash information online, right?

We could add additional constraints, lowering the allowed window to less than 18h. But it's good to know that it can't be more. That gives us a hard upper bound that we can rely on in algorithms.

The current behavior is that validation fails, which is equivalent to dropping the node. There is a long standing Github issue for adding a short-term "staging" cache for blocks that validation due to a temporary condition and may pass in the future.

We can get away with being absolute about timestamps for now (especially since our validate processing is slow), but some laxity in allowable clock skew is really desirable for distributed systems.

I think, iognoring blocks and considering them when they are recent adds this laxity.

If a node can generate and send blocks to a remote receiver in time t, and we have clock skew s >= t, we can get into a bizarre situation where nodes can only meaningfully participate on the network with other nodes that are sufficiently far away (where round-trip latency delays things long enough for time to catch up to the "future" blocks the skewed node is sending).

The current behavior doesn't ignore skew. It just doesn't include it into the protocol, but instead designs a protocol, that (hopefully) incentivizes the participants to keep their clocks synchronized (by associating an economic disadvantage with clock skew).
For instance, a mining node that produces blocks in the future (from the perspective of other nodes) will see its blocks ignored by other nodes. A validating node that commits on forks with blocks that are in the future (from the respective of other nodes) will find itself producing loosing forks. A miner that post-dates blocks may limit its ability to include recent transactions into their blocks.
The idea is to set the rules that the economically optimal strategy of each node is to minimize clock skew.

The comment on the blockCreationTime field of Chainweb.BlockHeader.BlockHeader, mentions that we still have to check that the assumptions behind the current protocol actually hold under different attack models.


Testing i2c-bus NPM Package

Testing the i2c-bus NPM package on the raspberry pi.

Throwing this issue out the window


Build instructions

I'm concerned that pbccs may depend on a version of seqan that has PacBio modifications.

oh nm, I see we have our own fork of seqan on GH


Add additional inputs

What

Utilize all aws_instance attributes and arguments

Why

In order to have the ability to add additional inputs

has been tested
module "admin_tier" {
  source                      = "../terraform-aws-ec2-instance"
  ssh_key_pair                = "sweetops"
  github_api_token            = ""
  github_organization         = ""
  github_team                 = ""
  vpc_id                      = "some_id"
  security_groups             = ["some_id"]
  subnet                      = "some_id"
  associate_public_ip_address = "true"
  name                        = "kafka"
  namespace                   = "cp"
  stage                       = "dev"
  additional_ips_count        = "1"
  ebs_volume_count            = "2"
}

Can confirm that user_data works properly, instance is available.

EBS attachment works

Additional EIPs work

But interface configuration should be added manually


Adding links for Trello and Gitter to dev branch.

What kind of change does this PR introduce?
Just adding two lines to the Status section of the Readme for the Gitter lobby and Trello board.

** Can it be referenced to an Issue? If so what is the issue # ?**
#506
How can we test it?

Just click em. :-)
Summary

Does this PR introduce a breaking change?
Nope
Other information

I think this way that 2 links are not very visible, but it is ok to put them on the 'Status' section.
Maybe it is better to move the entire 'Status' section above, e.g. after the 'What marker based means' section.
What do you think about that?
Also, when this is 'validated', it will be great if you can align master and dev readme with another PR

I was going for the minimum changes at first, but your comment is dead on and brings up some other thoughts.
There is already a link to the Trello board from the bottom of the Index, which I left in place because too much information is usually better than none.
Perhaps a larger and more efficient change would be to add a 'Community' section to the readme right after the Related Projects section, then consolidate links to various other repos/discussions/etc there?
And I will absolutely submit a PR for the same change in the master once the dev changes are in place. :-)
Thanks!
Thor

ok for me, you can go with the Community section :)

Ok, moved things to the new Community heading.


CSS custom properties aren't escaped properly

Description
When I add a string key with symbols in theme.extend.tokens.sizes i.e. '100%', I expect Panda to compile and allows me to use it in the css function as so
<span
  className={css({width: '100%'})}
>
...
</span>

Instead, it produces the unescaped CSS custom property --sizes-100% instead of --sizes-100\% which doesn't work.
When I try to manually escape it like so '100\%', it produces same output.
Link to Reproduction
https://stackblitz.com/edit/vitejs-vite-ypxbmx?file=panda.config.ts,src%2FApp.tsx&terminal=dev
Steps to reproduce
Inspect the CSS output of the reproduction to see CSS syntax errors for width not being applied.
JS Framework
Vite (TS)
Panda CSS Version
0.13.1

You can use a double backslash as a workaround for now .100\\%


Generic reducer operation

This is an operation, so it is similar in scope to Content::flatten.
The generic reducer operation reduces list depth by 1, much like the Content::flatten operation. It takes an array at some depth (axis parameter, just like flatten), a function of two arguments (maybe templated by array type?), and an identity (of that same type).
Once the generic reducer is in place, all concrete reducers can be implemented. They are:

reducer
type
binary function
identity

any
boolean
logical or
false

all
boolean
logical and
true

count
any
+1 for each argument
0

count_nonzero
numerical
+1 for each non-zero argument
0

sum
numerical
+
0

prod
numerical
*
1

min
numerical
x < y ? x : y
inf

max
numerical
x > y ? x : y
-inf

For integer types, min and max should use the integer type's maximum and minimum value as an identity.
As a later enhancement, there should also be a way to skip None in arrays of OptionType.

In #51 and here, I said that negative axis should count upward from the first RecordArray; that is, axis=-1 would mean the outermost ListOffsetArray64 in

instead of the innermost ListOffsetArray64 (pointed to by contents["y"]). Although that seems like a good choice for flatten, it would be a bad choice for reducers. It's quite common to want to reduce the innermost level of a tree, even if they're inside of a RecordArray. In fact, awkward 0.x always applies to the innermost level; it was written before I realized that other levels were conceptually possible.
So negative axis parameters should count up from the leaves of the tree, passing right through any RecordArrays. The leaves of the tree might be at different levels, so a negative axis defined this way would do things that aren't possible with a positive axis (unlike NumPy).
This has consequences for flatten: the axis should not be interpreted different ways in different functions, so flatten should count up from the leaves of the tree, too!

Worth mentioning: the existence of reducers will also enable several other essential functions (though they are not themselves reducers):
def moment(self, n, weight=None):
   "Compute the n-th moment of an array with optional weight."
    with self.numpy.errstate(invalid="ignore"):
        if weight is None:
            return self.numpy.true_divide((self**n).sum(), self.count())
        else:
            return self.numpy.true_divide(((self * weight)**n).sum(), (self * 0 + weight).sum())

def mean(self, weight=None):
   "Compute the mean (average) of an array with optional weight."
    with self.numpy.errstate(invalid="ignore"):
        if weight is None:
            return self.numpy.true_divide(self.sum(), self.count())
        else:
            return self.numpy.true_divide((self * weight).sum(), (self * 0 + weight).sum())

def var(self, weight=None, ddof=0):
   "Compute the variance of an array with optional weight and possibly reduce it with a number of degrees of freedom."
    with self.numpy.errstate(invalid="ignore"):
        if weight is None:
            denom = self.count()
            one = self.numpy.true_divide(self.sum(), denom)
            two = self.numpy.true_divide((self**2).sum(), denom)
        else:
            denom (self * 0 + weight).sum()
            one = self.numpy.true_divide((self * weight).sum(), denom)
            two = self.numpy.true_divide(((self * weight)**2).sum(), denom)
        if ddof != 0:
            return (two - one**2) * denom / (denom - ddof)
        else:
            return two - one**2

def std(self, weight=None, ddof=0):
   "Compute the standard deviation of an array with optional weight and possibly reduce it with a number of degrees of freedom."
    with self.numpy.errstate(invalid="ignore"):
        return self.numpy.sqrt(self.var(weight=weight, ddof=ddof))


Everything is ok except constraints not work

Enviorment:
Laravel 5.1
Laravel-Administrator 5.0.5 / Also tested with src replacement with 5.0.8, both don't work

Part of Config File:
	'edit_fields' => [
		'maincategory' => [
			'title' => 'Main Category',
			'type' => 'relationship',
			'name_field' => "title",
			'constraints' => array('subcategory' => 'mainCategories'),
		],
		'subcategory' => [
			'title' => 'Sub Category',
			'type' => 'relationship',
			'name_field' => "title",
			'constraints' => array('maincategory' => 'subCategories'),
		],
	]

Part of Model File ProductMainCategory:
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;

class ProductMainCategory extends Model {

	public function products(){
		return $this->hasMany('App\Models\Product', 'main_category_id');
	}

	public function subCategories(){
		return $this->hasMany('App\Models\ProductSubCategory', 'main_category_id');
	}

}

Part of Model File ProductSubCategory:
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;

class ProductSubCategory extends Model {

	public function products(){
		return $this->hasMany('App\Models\Product', 'sub_category_id');
	}

	public function mainCategory(){
		return $this->belongsTo('App\Models\ProductMainCategory', 'main_category_id');
	}

}

Part of Model File Product:
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;

class Product extends Model {

	public static $rules = [
		'title' => 'required|max:30',
		'seasons' => 'required',
	];

	public function mainCategory(){
		return $this->belongsTo('App\Models\ProductMainCategory', 'main_category_id');
	}

	public function subCategory(){
		return $this->belongsTo('App\Models\ProductSubCategory', 'sub_category_id');
	}

}

check and see if the constraints work on the edit and filter but not the create.  There is a bug with the first create.  Once you click the edit on a model to get the knockout fireing then all creates work.  I'm working on this.

Same here with 4.16.7 .
It also works after edit on a model.

Yes, when I change the maincategory, the subcategory values do get correctly, but maybe the bug of javascript especially of select2(maybe the version is too old), I can't render it correctly.Nothing happened, but I do find the result fetched correctly.
As for contraints in filter, seedmed not work, when I try to change the options, seemed the event not been triggered. A very useful function,hope to be repair soon, if possible maybe you can give me more info about the location of related code, I can try to work on it.

Knockout seemed is not a very good option in such a project, It make the script too complex, and limited the javascript, it's hard for me to upgrade the javascript libs. Anyway, I love the script!


chore: replace gofmt with gofumpt

Description

Replaces gofmt with gofumpt in Makefile. To install gofumpt, run go install mvdan.cc/gofumpt@latest.
It also adds an extra option to skip pb.gw.go files from being analyzed.

closes: #XXXX

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Closed in favor of #1894


Allocator support.

It would be greate to get allocator support. (Possibly even PMR).

Hi Luis,
Good news! I committed a draft for allocator support.
My example compiles finely, but I don't know about your use case. Could you check and tell me, whether it compiled finely and worked?
Yours,
Jakob

Hey, cool thanks for the quick response!
I didn't build the library yet locally. We're currently evaluating Unicode libraries and the lack of allocator support was somewhat of a disadvantage for us. Good to see it implemented now. Inheriting from the allocator for EBO is a bit unconventional, but I guess including a full-blown compressed_pair is overkill here.
My use case would primarily be pmr. So maybe, if you have spare time, you could test it with std::polymorphic_allocator<> and std::monotonic_buffer_resource<>. If it works with std::allocator it should work with pmr just fine!
Cheers

Sure! I happened to have the time 😃
That's what I figured, inheriting does work very well for now I guess :)
PMR should work quite well 👍
Cheers,
Jakob

FYI: Right now, I fixed several bugs that I had not seen before (related to allocators).

I will close this ticket for now. If you should encounter any issues. Feel free to open it again ;)


uefi-raw: only explicit padding bytes to fight Miri problems (for upstream users)

IMHO, having implicit padding bytes in Low-Level types (used for Casting etc) is a bad idea. When you cast a &[MemoryDescriptor] to &[u8], Miri complains about uninitialized bytes.
Exporting one (or multiple) public _pad0 fields however is also not nice. So, we should identify all structs where this is relevant and come up with a solution. Perhaps, lets move to constructor-based types with private fields? This is breaking, how-ever.
Checklist

[ ] Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
[ ] Update the changelog (if necessary)

When you cast a &[MemoryDescriptor] to &[u8], Miri complains about uninitialized bytes.

I'd like to understand this better -- why is this cast being performed? In general we can't make the problems of uninit bytes go away by adding explicit padding fields, because our types often go over FFI boundaries and we don't control the C definition.
If you do need a "raw bytes" view of a type that may contain uninit bytes, use &[MaybeUnint].

I've updated the PR description. Please re-check and let me know what you think.

I don't get this check. What is its purpose?

I don't get this check. What is its purpose?

The check-raw code assumes nothing is allowed by default, then adds various exceptions for code we do want to allow. Rust is a big language, and we should be very intentional about any new types of code being added to uefi-raw since it's intended to hew closely to the C API. For this particular use case std isn't needed, anything that reads each byte of raw_bytes will work, e.g. let _ = raw_bytes.iter().fold(0, |acc, v| acc + v).

By convention, structs having a C representation should be explicit with their in-between padding fields.

This is debatable I think. For example, bindgen has an option to enable explicit padding but its not enabled by default.
MemoryDescriptor actually strikes me as a place where explicit padding is less useful, because the actual size of MemoryDescriptor can in general only be known at runtime by checking the desc_size returned from get_memory_map. In effect, there may be implicit padding between each element.
In general, adding padding bytes can indeed make serialization and deserialization easier, but there are a couple cons to consider:

The type's fields can become cluttered. Perhaps not such a big deal in this one case, but if we apply it everywhere for UEFI-ABI-compat types, some structs are going to have many padding fields.
If the type is constructed externally (e.g. by UEFI firmware), the padding bytes may not be initialized anyway, and so we're just kind of tricking Miri by making the padding bytes explicit in tests, but not helping with real-world usage.

I think it would really help to have an example of the code where you want this so we can discuss whether alternatives might work acceptably well. For example, perhaps there's something we can do with MaybeUninit<u8> that would work.


Good error message when using unsupported C++ version

Motivation
Beman contributors, users, and maintainers will sometimes use a C++ version that is unsupported by a given project. There should be clear feedback when this happens, especially when it happens accidentally.
Completion Criteria
This issue will be complete when:

[ ] There is clear error message is printed when using the exemplar repo with an unsupported C++ version
[ ] The Beman Standard is updated to either recommend or require that all Beman libraries do likewise

Guidance
A user-unfriendly error message might be a compiler returning an error like: error: expected '(' before 'constexpr'.
Instead, we would like something more literally describing to the user that the C++ version needs to use C++23 or newer.
Mentor
@bretbrownjr is happy to discuss, review, and answer any questions.

Related: https://github.com/beman-project/exemplar/issues/40
There's no current consensus on the approach.

Honestly I would advocate for a requirement to add a section in the README/ docs that explains what is the minimum C++ requirement in current project and what would it take to lower it (basically explaining why it is what it is).
We can then add a detection CMake script in exemplar that basically denies configuration and spits out "Minimum version: xx. Read the README for why".


Add resume to play_card

Adds a resume flag to play_card to resume from position in case there is already playback information for a folder.
This is important for audiobooks.
In case the resume fails (eg if the folder changed), a normal playback is done and the error logged.
Addreses issue #1945

I was wondering, if the the annotation if a folder should be resumed or not shouldnt rather be a property of the folder instead of defined in the RPC linked to a card?
I see that there is already a RESUME Status in playermpd/ but could it be that it is not used yet?
Maybe even a combination could make sense? I.e. allowing the play_card to have a resume argument with options True|False|None (default None).
If set to True|False, this overwrites any property of the folder. In case of None, this resumes or not depending on the RESUME status (ON|OFF) of the folder.

I am trying to sharpen the use case a bit:

Case 1: Play something (let's say an audiobook), pause and resume it all with the same card. We currently already have an option to toggle playing on repeating card swipes. This is done via the second swipe option.
Case 2: Play an audiobook, interrupt it and play something different, the come back to the same spot where we left off.
Case 3: Same as case 2, but allow to shut down the Box in between. The only different is that the resume information needs to saved to disc.

Case 2 and 3 is currently not implemented (bits and pieces are there). This is a feature that is available in 2.X and is planned for 3.X as well. But we were planning to rewrite the mpd interface module as there is a couple of issues with it. And then put this and a few other features in.
The way I read your comment, you would add to these cases to function to select on a per-card basis if the resume should actually be executed or not. Correct?

Thanks for sharpening!
I am going for Case 2 & 3. With my current implementation, these cases work now for me.
As I currently have it, it is configured in the the RPC call associated with a card if a folder is resumed.
I.e. a card has an RPC command play_card associated with an argument resume=True.
In such a case, a card would behave like Case 2 & 3.
What I am now also working on, is that the RESUME status of a folder honored. I.e. if RESUME=ON, it would behave like in Case 2&3 and attempt to resume when playing the folder. If RESUME=OFF not (i.e. the standard behaviour we currently have).
The good thing about this would be, that we could add an RPC toogle_resume that switches the RESUME status. This could then be linked to a button/card/Web GUI button to set this option on a per folder basis.
Does this make sense?

@votti I am not entirely following your comment. We do not care about folders in V3 like we did in V2. It all comes down to the card and it's assignment.. which can be a folder, an album or a single file. All of these possible options then would have to be supported by the "Resume" flag and especially for Option 3, this needs to be stored on disk.

Ah thanks a lot for the pointer.
I just was looking at the code and somehow assumed that play_card was the main function that needed to be supported. Eg for the second swipe functionality so far only this one works.
I actually did miss  play_song and play_album and that they are not yet logged and persisted in the music_folder_status.json file.
So I guess the steps to go from here is to add status tracking for albums/songs first? (Does this already have an open issue?).
Would you think that in order to get a resume functionality merged it first needs to support all 3 things (songs, album, folder) or would it be OK as well if this would be folder specific first?

Would you think that in order to get a resume functionality merged it first needs to support all 3 things (songs, album, folder) or would it be OK as well if this would be folder specific first?

Yes! (sorry for the late answer :-))

this is still in request state right ?

I want to look into this feature. We very much need playback resume controls, otherwise the user (my grandmother :)) would have to listen to the same intros dozens of times 🤔   Second Swipe on future3 is also not implemented AFAICT, right? Or is it possible to use that in the config e.g. cards.yaml?

This is a great feature to have. But a few requirements will determine the way to solve the problem. Maybe we can first define the requirements in the format of "As a user, I want to ..." before we go heads down. Maybe we can review the architecture to solve this before someone spends time on it. Thoughts?

Side note: I checked out v2.4, too, thinking that might "just solve it", but oh dear future3's RPC and config is much nicer :)
This PR is also probably not the best place to chat about what we (I) wish for.
Let's imagine the next step is to return the double swipe to pause/resume feature, so is there anything here to salvage that, you think? From my noob perspective it looks like the existing functions on future3/develop suffice, only the wiring in the RPC commands is missing?

I didn't quite remember which features had been implemented, there was a larger break since I last developed. If it's just to connect the existing feature to the RPC, the give it a try :-)

If possible I would like to set the resume with a jump of 10 sec backwards. Like I could do in Antennapod

I've just stumbled upon this PR after playing with code enhancements around this topics myself. My current code is here and has been tested for play_single for now: https://github.com/hoffie/RPi-Jukebox-RFID/commit/c4805cebb848e8aaafd69c43f497b09436e67169

The code currently addresses the above mentioned cases 1, 2 and 3.
I noticed that only the play_card method supports second swipe. play_card does not seem to be used out of the box in the current code base at all. I've added a comment regarding that and added tracking functionality to the more relevant play_single,  play_album and play_folder methods.
The tracking is implemented separately from playermpd in order to be able to re-use it in other/different implementations. It is currently implemented to handle mpd-specific data, but that could easily be made more generic.
The tracking re-uses the existing status information from the mpd polling thread.
The tracking only writes to SD card after some grace time or upon user interactions (e.g. stop/next) to keep SD wear low.
The tracking does not act on a per-folder level (which would break for album/single or totally different players). Instead, it uses a play_target, which is basically a combination of method call (e.g. play_single) with its arguments (SomeSong.mp3). That makes it flexible and reliable.
With this code in place, playermpd.status_file may become redundant (but I haven't removed it yet).

If there's any interest I'm happy to polish that commit further and submit it as a PR.

@hoffie, sounds like a cool addition.
Right now we are also working on a multi player support #2164, maybe it’s worth considering.

@s-martin What would be the best way forward? Should I wait for #2164 to be merged and rebase my code on that? Or should I rather submit a PR with my code right now?

We should check with @Groovylein how far the Multiplayer PR is?

@s-martin What would be the best way forward? Should I wait for #2164 to be merged and rebase my code on that? Or should I rather submit a PR with my code right now?

@hoffie: Let's try to get this merged. We'll have to do an extra effort for #2164 anyways.

I've just stumbled upon this PR after playing with code enhancements around this topic myself. My current code is here and has been tested for play_single for now: hoffie@c4805ce

@hoffie I added a few comments to your code

@pabera Thanks. I'll try to address your comments in my upcoming PR.  Will probably get to it by Thursday.
(Just for reference and probably not worth commenting there again: dca9d1b3f635e99e30f67540425b6a502921be57 is what I currently use in "production" without issues, even for whole folders)

I'll try to address your comments in my upcoming PR.

See #2331.

Fixed a merge conflict.
There is a flake8 error, which lets the checks fail, see https://github.com/MiczFlor/RPi-Jukebox-RFID/actions/runs/8944194290/job/24570588323?pr=1946

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 38.235%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
494

Relevant Lines:
1292

💛  - Coveralls

There was a question in the chat about the resume feature https://matrix.to/#/!keXiohOiVddsrZXwBu:gitter.im/$4AmKngehqk3CH9Uu1w1jpqL2rWNoZ-F7y4dRAy7cXGA?via=matrix.org&via=gitter.im&via=unsicher.net
Right now I'm not sure, if anything is missing so this PR could be merged?
@votti @pabera

I am using this "in production" for more than a year and by now have it enabled for almost any card.
Really a useful feature in my view that I would not want to miss any more.
I think it should be straight forward to refactor this in the future to a more generalized play tracking mechanism (eg as implemented here: https://github.com/hoffie/RPi-Jukebox-RFID/commit/1ab43a53fbf726d8502643924fe93086d217a9f8
). Thus I think it would be appropriate to merge now.

Thanks for the feedback!

I just got this branch working on a test pi, with the primary goal of providing basic audiobook resume functionality for my kids (ages 3-8).

rpi zero w
bookworm
rc522 reader (with rpi-lgpio shim for bookworm)

For reference, here is a working cards.yml entry:
'2788200895':
  alias: play_card
  args:
    - <folder_name>
  kwargs:
    resume: true

I have place_not_swipe: false set since the new behavior of a swipe while playing appears to provide play/pause toggle. I'm curious to see how that option would interact.
Since this is a relatively small code addition, perhaps it could be worked into #2330? Otherwise I also suspect it could be merged without too much trouble for the other related PRs.

Something I noticed recently, is that if the kids leave the card on the device, with resume=True the song will sporadically stutter as the box triggers a resume. I am very much looking forward to have second_swipe fully supported as this would make it easy to prevent it.

One workaround I implemented for myself was that I enabled play_folder to also support playing single files. Thus I can use play_cards (that ultivatively calls play_folders) for both single files and folders and the resume functionality also works for both: https://github.com/votti/RPi-Jukebox-RFID/commit/f8e9de729f6fab1028335118e119434de5815612

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 38.14%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
492

Relevant Lines:
1290

💛  - Coveralls


cgroup nesting warning

cgroup: docker (797) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
cgroup: "memory" requires setting use_hierarchy to 1 on the root

Fixed via sysctl


WMO doodad sets use wrong index when loading

Turns out MODR indices should be taken against MODD, and not against MODD-intersected-by-MODS.
We should adjust doodad loading in WMOHandler to subtract MODS.start from doodadIndex prior to pulling the entry out of the filtered doodad set.

I'm assuming the current implementation should result in some funky stuff by loading the wrong doodads? Do we have any examples? Would love to see that 😄

It's less that wrong doodads are loaded (although I'm sure if we looked closely, we'd see some wrong doodads), and more that doodads wind up associated with wrong WMO groups. I figured out this was happening when I implemented portal culling -> doodad visibility and wound up with very weird doodads disappearing or reappearing.


Sky boss v05

I have now coded up and spot-checked two new BOSS skies cartons
ops_sky_boss_best
ops_sky_boss_good
I have removed the old obs_sky_boss and ops_sky_apogee cartons from python/target_selection/cartons/ops_skies.py
I have also included a sketch of the logic for one more:
ops_sky_boss_fallback
These are associated with version '0.5.7' in python/target_selection/config/target_selection.yml

Hi @albireox , @astronomygupta
I'll let you take the last decision on whether to merge this pull request
thsnks, Tom

Hi @tdwelly, this looks all fine to me. @astronomygupta can you please merge and give a try to running the two cartons already implemented? Then can you try to create a new carton ops_sky_boss_fallback using Peewee from the SQL that Tom included? It doesn't seem terribly difficult but let me know if you run into problems.


HHVM Statement Wrapper Fatal Error

Fatal error: Class Propel\\Runtime\\Connection\\StatementWrapper cannot implement both IteratorAggregate and Iterator at the same time in /vagrant/vendor/propel/propel/src/Propel/Runtime/Connection/StatementWrapper.php on line 17
On Ubuntu 16.04, HHVM 3.23.2, using SQLITE as database type.

+1

Tried changing implemented interface in StatementWrapper class from \IteratorAggregate to \Iterator and it works for HHVM but not for PHP

Is someone able to make a PR here with suggested changes?


InitializePhase2() and CleanUp() methods are never called

InitializePhase2() and CleanUp() methods should be defined as virtual in ExtensionMain so that extensions can implement these methods for additional processing. The immediate need is for the Replicator widget to be able to run v3.0 of the harvest extensions. The harvest extensions need to deinitialize the site-harvest extension at the end of each scenario run so that it can be reinitialized for the succeeding run(s).
This method should be available for all extensions as it is good practice to clean-up resources,such as logs, when a scenario finishes running. It isn't currently an issue with the command line interface because all processes end after each scenario but pose future problems if the scenarios are run through a different UI.
The risk related to this implementation is that extensions with InitializePhase2() and CleanUp() methods that have not been running will start running.
This issue needs to be resolved before LANDIS-II-Foundation/Tools#3 and LANDIS-II-Foundation/Extension-Base-Harvest#5 can be tackled.

Input from Jimm Domingo 3-NOV-2015:
I'm not sure the methods would start to run.  If a developer had written CleanUp or InitializePhase2 methods in an extension, she would've had to use the "new" keyword to hide the non-virtual counterparts in the ExtensionMain base class.  Otherwise, the compiler would complain.  So she would've silenced the compiler even though the core couldn't access the methods in the extension's Main class.
If those 2 methods are made virtual in the ExtensionMain, then extension developers have to use the "override" keyword.  So if they had written CleanUp or InitializePhase2 methods, they'd have to change their signatures.  IOW, they'd need to update the source code.  So it's not a source-compatible change.  I don't know if changing the signatures of the methods in ExtensionMain is binary-compatible.
If it's not (i.e., it's binary-incompatible), the core wouldn't be able load any extensions with those definitions of those methods.  If it is a binary-compatible change, the core may be able to load those type of extensions, but it may not be able to call those methods because the methods are defined with the "new" keyword.  My C# is a bit rusty of late, but I don't think methods defined that way are accessible via the base class (which is how the core accesses all the exension's Main classes -- through the ExtensionMain base class).  That'll need to be checked out further with some test code.
This change (making those methods virtual) is looking like it may be an API-breaking change.  And such a change means a bump in the major version (L-II 7.0).  It'd be a lot of work, but it may be worth surveying the source code of existing extensions to see if any of them define a CleanUp or InitializePhase2 methods.

Made the change to ExtensionMain.cs on the Widgets branch. With accompanying changes to the Site Harvest Lib and Base Harvest Extension, it solves the problem we are trying to solve. However, given Jimm's comments, we should probably push the version to at least 6.2 which requires additional code changes. Waiting to get approval from TAC before proceeding further.

Summary for TAC:
The ExtensionMain class is the base class for all extensions. The model core controls the extensions using methods and properties that defined in the ExtensionMain class. There are two methods in ExtensionMain defined incorrectly so that they cannot be implemented/defined in an extension. These methods are InitializePhase2() and CleanUp(). These methods are executed by the model core but nothing happens because they cannot be implemented/defined in an extension.
InitializePhase2() is called after all extensions have initialized potentially allowing additional initialization functionality that relies on the initialization of an extension. CleanUp() is called after all timesteps of a scenario have run. This allows an extension to clean up after itself by releasing resources such as "handles" to log files. If a handles is open on a log file, no other processes or programs can access it.
We recommend that the definition of these two methods be changed from void to virtual allowing extensions to "override" these methods and implement functionality within them. We have been told that this was the original intention for these methods but that an error was made when this code was refactored in the past. We also recommend that the core version be updated from 6.1 to 6.2 as this is a significant change.
The immediate need for this change is to allow scenarios to be run sequentially using the "Widgets" Replicator or Launcher. Since the current implementation doesn't support the CleanUp() method, many extensions hold open resources so the scenario cannot run a second time. This is not a problem when running LANDIS-II from the console because resources are automatically cleared at the end of a scenario. This is inherent with how the console works but Windows applications (widgets) control memory differently. This could also pose a problem in the future when running LANDIS-II on the cloud depending on how the application is run.
See Jimm Domingo's comment from NOV 3 on the risk involved in making this change. We recommend that it be reviewed by one or more experienced C# developers in the LANDIS-II community and also that a repository search be done (if possible) for the use of  InitializePhase2() and CleanUp() methods in existing extension code.

ready to close


Can i make all possible combinations in JSON array sets;

When i change the code of JSON array to combine 3 companies, that is Radiohead, Bach and Eminem i.e., [0,7,4] sets in JSON array, the changes of new intersection among these 3 companies does not reflect in the Venn diagram.
the changes in the JSON array is as follows ~~> "  {"sets": [0, 4, 7], "size": 110},  "
please help me understand if there is any possibility that may overcome the above issue ?

Its an optimization process - its impossible to show diagrams like that one correctly, so its trying to do the best possible representation. I suspect that changing that area isn't sufficient to make a difference in the final layout.
Specifying an optional weight here can give this area extra importance in the optimization process. There is an example here http://benfred.github.io/venn.js/examples/weighted.html


Add Scene Metadata Support

Add scene level metadata support

can you also update the sceneSerializer?

Ok... I added:
// Metadata
if (scene.metadata) {
serializationObject.metadata = scene.metadata;
}
to sceneSerializer... But i never did this for node.metadata.
Because node.metadata has @serialize, does it also need to be handled in sceneSerialize or is that automatic... What about mesh.metedata... I had to manually "Parse" mesh.metadata... So do i need to do anything with node.metadata in sceneSerilizer ?

Correct
We need to do it for the mesh serialization (only)
Other nodes are already handled

Done.


Vision Camera V3 support

An update that removes the reanimated dependency and supports worklets-core would be most welcome.

This is on my plan. I will try to upgrade the plugins soon.

V3 is just released and has bugs. The progress is stuck.
I've opened several issues:

https://github.com/mrousavy/react-native-vision-camera/issues/1778
https://github.com/mrousavy/react-native-vision-camera/issues/1774

Much appreciated @xulihang Hope the recent push on 3.1.0 helped out the progress

Good luck @xulihang we appreciate your time and effort maintaining this!

@xulihang same question for this repo, do you have an ETA on when it will work with v3? If not would you like some help? I can try to put in a PR to make it work.

I got stuck running Android at this issue: https://github.com/mrousavy/react-native-vision-camera/issues/2066 I will try to build in on Mac to try again. PRs are welcome. V3's code lies in the vision-camera-v3 branch.

Version 1.0.0 of the plugin is now compatible with vision camera v3.


[miner] databaseURL is not used anymore so can remove it.

I did a quick search and don't think the miner actually supports a remote DB so need to investigate and remove if unused.

I think when you remote mine it uses it