Socrata-SBT-plugin

Updated the code to include new socrata-sbt-plugin.

soda-fountain #304 FAILURE
Looks like there's a problem with this pull request

changing cloudbees configuration from
+clean +compile +scoverage:test +package +assembly
to
+clean +compile +coverage +test +package +assembly

soda-fountain #305 FAILURE
Looks like there's a problem with this pull request

this is looking good so far, but there are still some problems. sbt test didn't succeed.

soda-fountain #307 FAILURE
Looks like there's a problem with this pull request

soda-fountain #308 SUCCESS
This pull request looks good

:shipit: good enough to build and publish


Running MPI enabled coreneuron without srun/mpirun causes Floating point exception (with HPE-MPI)

While running on BB5, I see following:
$ ./x86_64/special-core -e 100 -d testkindat/ --gpu

 Duke, Yale, and the BlueBrain Project -- Copyright 1984-2019
 version id unimplemented

....

 Start time (t) = 0

 Memory (MBs) :  After mk_spikevec_buffer : Max 196.2578, Min 196.2578, Avg 196.2578
Floating point exception

And enabling FPE with GDB shows:
 >> gdb ./x86_64/special-core

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
...

(gdb) r -e 100 -d testkindat/ --gpu
Starting program: /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/testcorenrn/./x86_64/special-core -e 100 -d testkindat/ --gpu
.....

Program received signal SIGFPE, Arithmetic exception.
0x00007fffed12b0b2 in MPI_SGI_comm_fetch (comm=comm@entry=1) at comm.c:36
36	comm.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libbitmask-2.0-721r1.rhel77hpe.x86_64 libcpuset-1.0-721r191009T2000.rhel77hpe.x86_64
(gdb) bt
#0  0x00007fffed12b0b2 in MPI_SGI_comm_fetch (comm=comm@entry=1) at comm.c:36
#1  0x00007fffed1352f7 in MPI_SGI_comm_get (comm=1) at ../../../../include/comm.h:182
#2  MPI_SGI_comm_is_inter (comm=1) at ../../../../include/comm.h:198
#3  PMPI_Comm_split_type (comm=1, split_type=1, key=0, info=0, newcomm=0x7fffffff7c80) at comm_split.c:606
#4  0x0000000000481d6e in nrnmpi_local_rank () at /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/coreneuron/coreneuron/mpi/nrnmpi.cpp:237
#5  0x000000000044bd9c in coreneuron::setup_nrnthreads_on_device (threads=0x1414ab0, nthreads=2)
    at /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/coreneuron/coreneuron/gpu/nrn_acc_manager.cpp:961
#6  0x0000000000445927 in coreneuron::nrn_init_and_load_data (argc=6, argv=0x7fffffff8da8, is_mapping_needed=0 '\000', nrnmpi_under_nrncontrol=<optimized out>,
    run_setup_cleanup=1 '\001') at /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/coreneuron/coreneuron/apps/main1.cpp:290
#7  0x000000000042d30c in run_solve_core (argc=6, argv=0x7fffffff8da8) at /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/coreneuron/coreneuron/apps/main1.cpp:468
#8  0x00000000004141b0 in solve_core (argc=6, argv=0x7fffffff8da8)
    at /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/coreneuron/build_master/install/share/coreneuron/enginemech.cpp:40
#9  0x0000000000414189 in main (argc=1, argv=0x7fffed489809 <mpi_sgi_thread_safe>)
    at /gpfs/bbp.cscs.ch/data/project/proj16/kumbhar/pramod_scratch/coreneuron/build_master/install/share/coreneuron/coreneuron.cpp:34

Seems this has been fixed already. Cant reproduce on BB5 with latest master.


Where are ISO-images for testing?

Unfortunately, we're not at that stage yet.  If you want to play around with harvey, take a look here: https://github.com/Harvey-OS/harvey/wiki/Getting-Started

Here's the distro project: https://github.com/Harvey-OS/harvey/projects/3


composer package should not include '-php'

To be consistent with our other libraries, this package in composer should be google/proto-client

This makes sense. I will sync this change with the switch to the new proto3 implementation, to do all the breakage at the same time.

Resolved in #29


Unsupported major.minor version 51.0

Seems like this issue has resurfaced:
https://groups.google.com/forum/#!topic/j2objc-discuss/6ceJr8-y0WU
This is when trying to build
https://github.com/tomball/j2objc-sample-reversi
using
Xcode 7.1.1
with
https://github.com/google/j2objc/releases/tag/<IP_ADDRESS>.1
in the correct path.

As described in the http://j2objc.org Requirements section, Java 7 is now the minimum version of Java we work with.

I have installed Oracle JRE 8, but can’t find a way to get j2objc use it instead of the Apple Java. Any pointers?

It's nothing specific to j2objc: every Java developer on a Mac needs to now
set their environment using /usr/libexec/java_home in their ~/.bash_profile
(and log out and back in). The good news is that switching between Java
versions is now much easier:
http://stackoverflow.com/questions/6588390/where-is-java-home-on-osx-yosemite-10-10-mavericks-10-9-mountain-lion-10
On Wed, Dec 2, 2015 at 2:24 AM Jan<EMAIL_ADDRESS>wrote:

I have installed Oracle JRE 8, but can’t find a way to get j2objc use it
instead of the Apple Java. Any pointers?
—
Reply to this email directly or view it on GitHub
https://github.com/google/j2objc/issues/668#issuecomment-161249837.

I'm sorry for the recent build failures. We're cleaning things up for a 1.0 release, and some of those changes were unfortunately disruptive.


Automated cherry pick of #2988: cronjob support remove

Cherry pick of #2988 on release/2.11.
#2988: cronjob support remove

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.11@3d6a1ec). Click here to learn what that means.
The diff coverage is 52.43%.

@@              Coverage Diff               @@
##             release/2.11   #2990   +/-   ##
==============================================
  Coverage                ?   7.17%
==============================================
  Files                   ?     476
  Lines                   ?   76562
  Branches                ?       0
==============================================
  Hits                    ?    5494
  Misses                  ?   70604
  Partials                ?     464

Flag
Coverage Δ

#aFlag
7.17% <52.43%> (?)

Impacted Files
Coverage Δ

pkg/cloudcommon/cronman/cronman.go
54.54% <52.43%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3d6a1ec...a0d4cd3. Read the comment docs.


Error at the end of the Quest

Hi,
When a player finish a quest there is a console error message :
LOG:
[19:06:50] [Server thread/ERROR]: [Quests] An error has occurred with Quests. Please report on Github. Include the info below
[19:06:50] [Server thread/WARN]: [Quests] index = 0
[19:06:50] [Server thread/ERROR]: Could not pass event PlayerMoveEvent to Quests v3.7.8-b16
org.bukkit.event.EventException: null
	at org.bukkit.plugin.EventExecutor$2.execute(EventExecutor.java:72) ~[patched_1.12.2.jar:git-Paper-1613]
	at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:78) ~[patched_1.12.2.jar:git-Paper-1613]
	at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62) ~[patched_1.12.2.jar:git-Paper-1613]
	at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:513) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.PlayerConnection.a(PlayerConnection.java:697) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.PacketPlayInFlying.a(SourceFile:126) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.PacketPlayInFlying$PacketPlayInPosition.a(SourceFile:57) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.PlayerConnectionUtils.lambda$ensureMainThread$0(PlayerConnectionUtils.java:14) ~[patched_1.12.2.jar:git-Paper-1613]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_212]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_212]
	at net.minecraft.server.v1_12_R1.SystemUtils.a(SourceFile:46) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.MinecraftServer.D(MinecraftServer.java:850) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.DedicatedServer.D(DedicatedServer.java:423) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.MinecraftServer.C(MinecraftServer.java:774) ~[patched_1.12.2.jar:git-Paper-1613]
	at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:666) ~[patched_1.12.2.jar:git-Paper-1613]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]
Caused by: java.lang.NullPointerException
	at me.blackvein.quests.Quester.reachLocation(Quester.java:1721) ~[?:?]
	at me.blackvein.quests.listeners.PlayerListener.onPlayerMove(PlayerListener.java:864) ~[?:?]
	at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor805.execute(Unknown Source) ~[?:?]
	at org.bukkit.plugin.EventExecutor$2.execute(EventExecutor.java:70) ~[patched_1.12.2.jar:git-Paper-1613]
	... 15 more

Example quest:
  mission6:
    name: Rôtisserie
    ask-message: §6§nAccomplissez dans l'ordre:§7 Tuer 100 Poules...
    finish-message: ''
    requirements:
      permissions:
      - niveau.1
      fail-requirement-message: §8[§4✘§8] §cVous devez être Niveau 1 pour effectuer
        cette Mission.
    stages:
      ordered:
        '1':
          mobs-to-kill:
          - chicken
          mob-amounts:
          - 100
          death-event: DeathFail
        '2':
          locations-to-reach:
          - world 7.0 70.0 7.0
          reach-location-radii:
          - 3
          reach-location-names:
          - Spawn
          death-event: DeathFail
          objective-override: §7Retourner au Spawn
    rewards:
      commands:
      - pex user <player> add mission.6
      - pvplevels message <player> &8[&2✔&8] &7Mission &5Rôtisserie &7Terminée ! Félicitations
        !
      - recompense1 <player>
      - bc &6<player> &7a terminé la mission &5Rôtisserie &7!
      commands-override-display:
      - ''
    options:
      allow-commands: true
      use-dungeonsxl-plugin: false
      use-parties-plugin: true

I don't know what is the problem, it appear since last update.
Thanks for your help !

Hi,
Any news about the problem please ?
Thanks'

This was caused by your quest having 3 command rewards, but only 1 command display override. You should either have as many overrides as you do commands, or none at all.
Using this build will resolve the error, but unless you fix what I just mentioned, rewards may not appear as desired at the end of your quest:
https://ci.codemc.org/job/PikaMug/job/Quests/24/


Add tiny icons for line items

Problem/Feature
For line item rows in the new conversation view design, we needed to add two new icons because (per design) the size of the current icons is not appropriate for use in that context.
So this PR adds those two new icons from @kyliedunkley! 🥳

Note: It was stressed to Kylie that these should be "tiny icons"™. I couldn't find any references to what "tiny icons" means searching in various places and this is the only Icon component I know about (and its size prop is number based rather than small medium large etc), so I assume these go here and maybe that was just some design hazing™, but if I should be putting them somewhere else or doing something different, let me know!
Guidelines
Make sure the pull request:

[ ] Follows the established folder/file structure
[ ] Adds unit tests
[ ] If it is a refactor or change to an existing component, have you verified it won't break existing Cypress tests or have you updated them?
[ ] Did you verify some accessibility (a11y) basics?
[ ] Adds/updates stories. Guidelines
[ ] Adds/updates documentation (ie proptypes) Guidelines
[ ] Has it been tested in Help Scout's supported browsers?
[ ] Requests review from designer of the feature
[ ] Add label (bug? feature?)

💯  will do, thank you!


Mixins generates wrong font file name when unicode-range subset is number

Describe the bug
mixins generates wrong font file name so error thrown while building.
It affects every fonts that $unicodeMap is mapped by number, especially CJK fonts (noto-sans-*, noto-serif-*, ...)
My environment is:

vue 2.6.12
webpack 4.46.0
sass (dart-sass) 1.32.6

To Reproduce
build with this source
@import '~@fontsource/noto-sans-kr/scss/mixins';

@include fontFace($weight: 300);
@include fontFace($weight: 400);
@include fontFace($weight: 500);

throws error below
Syntax Error: ModuleNotFoundError: Module not found: Error: Can't resolve<EMAIL_ADDRESS>in '/workspace/packages/app-user/src'

actual file name should be noto-sans-kr-0-300-normal.woff2.
Expected behavior
change index like [0] to just numeric like 0 or '0' to work.

Ah, we just need to strip the square brackets when inputting the variables into the template file. Should be a very simple fix.
Appreciate the issue.


Generate insert queries with prefixes

Hey @mickeypearce, take a look when you have the chance.
I wrote some tests for get table names function.


RFC Check for constant existence before declaring

I use an tool which requires the composer autoloader.php in order to use the class map.
When this tool is used with the library it issues a warning as these constants are then redefined.
This PR checks for the existence of the constants before defining them.

This is probably a bug in that tool then and should be fixed there.

I'm not sure it can be classed as a bug - the tool needs the ClassLoader from composer for a given project, and this is the only easy way to facilitate that, so it's by design.
An extension for the tool also uses amphp/process, so when including for the project it fails.
Other tools also include the autoloader additionally (e.g. Phpstan, WorseReflection), but don't use amphp/process so it's not an issue.
For sure, it's not a nice thing to do in general (importing somebody elses autoloader) but I'm not sure there's a better way currently.

Why are only the constants a problem, but not the function definitions? They'd be declared twice, too.

hmm, good point, this PR did fix the issue however, so that's confusing.
I can't reproduce now even with the extension, closing. Will re-open if it occurs again and I can further isolate the issue.

@dantleech The two constants in question are defined within the scope of a namespace. Unless the other application is defining code within that same namespace, there shouldn't be any collision of constants here.
Basic CLI example (with XDebug on) of referencing a constant inside a namespace, as well as failing to specify the namespace of the constant while outside the namespace:
 $ php -r "namespace Foo; const BAR = 'FooBar'; namespace FizzBuzz; var_dump(\Foo\BAR); var_dump(BAR);"
string(6) "FooBar"
PHP Warning:  Use of undefined constant BAR - assumed 'BAR' (this will throw an Error in a future version of PHP) in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0

Warning: Use of undefined constant BAR - assumed 'BAR' (this will throw an Error in a future version of PHP) in Command line code on line 1

Call Stack:
    0.0040     391280   1. {main}() Command line code:0

string(3) "BAR"


Meta Title and Meta Keywords are not saving

The Meta Title and Meta Keywords are not saving.
It says: "You have not set a meta title."
Even I've already added the title.
php: 7.4.22
mysql: 8.0.3
silverstripers/seo: latest
os: windows 11

Hello @genesisbertiz does this happen on the master branch? Well, suggest you to use PHP 8.1 > and Silverstripe 5 is possible. Let me know the version you are using please.


Fixes 10709: Add useFqnForFiltering to profiler workflow

Describe your changes:
Fixes #10709: Add useFqnForFiltering to profiler workflow

I worked on ... because ...

Type of change:

[ ] Bug fix
[ ] Improvement
[ ] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] My PR title is Fixes <issue-number>: <short explanation>
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

Failing tests, not related to the PR


TTB Metadata persists even after updating the key with a TTL

Describe the bug
A key set with a TTB has to be deleted before a TTL can be set.. Sample below the updated key is still only visible after 60seconds
To Reproduce
Steps to reproduce the behavior:

Create a key with a TTB and then update that key with a TTL
The TTB persists and you have to delete the key and then set the TTL
Looks like a secondary code problem as the atClient sends the right metadata

Expected behavior
Old meta data should be ignored when the key is set
Screenshots
'''
var metaData = Metadata()
..isPublic = true
..isEncrypted = false
..namespaceAware = true
// // one minute
..ttb = 60000 ;
var key = AtKey()
..key = hamradio.radioName
..sharedBy = currentAtsign
..sharedWith = null
..metadata = metaData;
;
await atClient.put(key, message)
var metaData = Metadata()
..isPublic = true
..isEncrypted = false
..namespaceAware = true
// // one minute
..ttl = 60000 ;
var key = AtKey()
..key = hamradio.radioName
..sharedBy = currentAtsign
..sharedWith = null
..metadata = metaData;
;
/// await atClient.delete(key); <- This line should not have to be used
await atClient.put(key, message)
'''
Additional context
Add any other context about the problem here.

Feature or bug @VJag will review

Seems like a bug ... @VJag what are next steps with this?

One way to deal with the problem is:

I have tried deleting the key and that worked fine.. I have to try setting to Zero.
I either case a sample/example would help here in the documentation

I will take care of adding a sample code for setting/resetting TTL/TTB

Is the correct behaviour here that setting a TTL should always clear any existing TTB? And also should we (or do we already) prevent something trying to set both a TTB/TTL at the same time?

@gkc : At the moment, TTL and TTB are not mutual exclusive. For a same key if TTB and TTL are set, the key is available when TTB is met and expires after the time mentioned in TTL.
Also we have a way to reset the TTB in metadata. Setting to 0 would make the key available immediately. However this requires a minor code change (Modify IF condition that checks the TTB value) which are done in local and tested. Attaching the test log.
@sitaram@update:ttb:100000:@sitaram:key4@sitaram value4
data:5
@sitaram@llookup:@sitaram:key4@sitaram
data:null
@sitaram@update:ttb:0:@sitaram:key4@sitaram value4
data:6
@sitaram@llookup:@sitaram:key4@sitaram
data:value4
@sitaram@


0.3 CLI design

Overview
As part of the planned 0.3 release (codename cloak), the dagger CLI is getting a redesign. There are currently several concurrent designs:

"Europa design": this is the current design of dagger 0.2.x. It is specific to CUE and is intended for direct human use only, not embedding in a host program.
"Cloak prototype design": this is the current design of the cloak binary in the cloak branch. It is our de-facto design for 0.3, but it has not been explicitly designed: it simply evolved organically from layers of prototyping.
"0.3 CLI design": the design we should use for the stable release of Dagger 0.3, and ideally as early as 0.3.0-alpha.1. This design does not yet exist: defining it is the subject of this issue.

When to close
This issue is considered complete when consensus is reached on the 0.3 CLI design, and documented in a way that allows unambiguous implementation.

[ ] Kickstart proposal
[ ] Bikeshedding in comments
[ ] Rough consensus
[ ] Polish
[ ] Start implementation

Design proposal
Two strawman proposals below. Bikeshed away.
Option 1: all-in-one binary
The dagger CLI, also known as the Dagger Engine, has two functions visible to end users: a client and a worker. It also has two hidden functions, for internal use as plumbing: a gateway and an exec shim.

Function
Visible to end user
Command
Runs on..
Run by…
Description

Client
✅
dagger without argument
Client machine
Interactive terminal or shell script
Send graphql queries to a worker

Worker
✅
dagger worker
Worker machine
Container runtime: docker, containerd, podman, systemd, kubernetes, lxd
Serve API requests and run pipelines

Gateway
👻
dagger gateway
Client machine
SDKs
Smart proxy that implements the hard parts of the Dagger API so that SDKs don’t have to. Features: host access callbacks; namespacing; authentication to Dagger Cloud; pluggable logging, tracing and telemetry; policies; provisioning; cache configuration

Executor
👻
dagger exec
Worker machine
worker
Execute a command inside a container orchestrated by the worker

Option 2: client only
Architecture
graph LR

subgraph "Client machine"
term["Terminal"]
script["Shell script"]
sdk["SDKs (except go)"]
cli["CLI"]

term & script & sdk -..-> cli
end

subgraph "Worker machine"
engine["Engine"]
runtime["OCI container runtime"]
end
cli --> engine -..-> runtime

Dagger CLI
The dagger CLI is a client tool for interacting with the Dagger engine. It can be called from the terminal or a shell script, or instrumented by custom tools. Most Dagger SDKs instrument the CLI to save time on implementation.
$ dagger --help
A command-line client for dagger, the programmable CI/CD engine that runs your pipelines in containers

Usage:
  dagger [flags]

  By default, dagger establishes a connection to an engine, reads graphql queries from standard input, sends them to the engine for execution, and prints the result.

  Flags:
  -h, --help             help for dagger
  --listen ADDR  Listen on network address ADDR, and proxy traffic to the engine. Useful for graphql tooling.
  --var      Pass variable to a query
  --doc     Graphql document from which to read operations
  --op       Select an operation from the graphql document
  --workdir string   The host workdir loaded into cloak
  --engine NAME|ADDRESS  select an engine to connect to

Dagger Engine
The Dagger engine serves API requests and runs pipelines. It is released as an OCI container image, and installed on a worker machine. This can be done manually by a sysadmin, using a custom infrastructure provisioning tool, or with the auto-install feature of the CLI.
The Dagger engine is made of several sub-components. The nature and layout of those sub-components is private: it may change from one release to the next. Only the OCI container image is considered a publicly consumable release of the engine.
At the moment, sub-components include:

Exec shim (dagger-engine-shim)
Instrumented buildkit daemon (dagger-engine-buildkitd)
API server (dagger-engine-api)

Do not rely on the interface of these sub-components as they can change at any time.
Open questions
FIXME

@shykes who owns this issue to ensure we get an agreement on the proposal or will that be you? Also, should I add this to the #3283 release checklist?

@shykes who owns this issue to ensure we get an agreement on the proposal or will that be you?

I can drive it, assigned it to myself to clarify.

Also, should I add this to the #3283 release checklist?

Yes I believe so 👍 cc @gerhard

dagger gateway as described there shouldn't be a public function right? I don't see that users would ever need to call it.

dagger gateway as described there shouldn't be a public function right? I don't see that users would ever need to call it.

Yes I guess it could be hidden from the help message (though still documented somewhere?) Is that what you mean?

To calibrate expectations, my understanding is that this will happen in parallel to the binary (a.k.a. engine) release work. While we would like to have this issue closed before 0.3.0-alpha.1 is produced, we should not approach it in sequence, i.e. close this issue first, then move onto the release process. As I mentioned elsewhere, I don't expect us to get the engine release process right with the first alpha release, and I think that we are likely to have a few before we are confident that everything works as expected.
While in the alpha stage, anything goes from an artefact perspective. Even if the binaries are different and incompatible, that is OK because the focus is on how all the various systems integrate in the release process:

GitHub tags & pre-releases
Homebrew tap
install.sh (this implies AWS S3 & CloudFront)
install.ps (we are deferring this towards the end)

Let me know if you think differently.

dagger engine & dagger gateway make sense as proposed.
I am wondering if dagger exec & dagger client could be a single command. I am leaning towards dagger exec since it's familiar & comfortable - the shell built-in exec command.
What do you think @shykes?

dagger engine & dagger gateway make sense as proposed.
I am wondering if dagger exec & dagger client could be a single command. I am leaning towards dagger exec since it's familiar & comfortable - the shell built-in exec command.
What do you think @shykes?

exec is very different, it’s the shim that will be run by buildkit at the very bottom of the stack. It is functionally a completely different command, just bundled in the same CLI purely for reasons of convenience of packaging.

To calibrate expectations, my understanding is that this will happen in parallel to the binary (a.k.a. engine) release work. While we would like to have this issue closed before 0.3.0-alpha.1 is produced, we should not approach it in sequence, i.e. close this issue first, then move onto the release process. As I mentioned elsewhere, I don't expect us to get the engine release process right with the first alpha release, and I think that we are likely to have a few before we are confident that everything works as expected.
While in the alpha stage, anything goes from an artefact perspective. Even if the binaries are different and incompatible, that is OK because the focus is on how all the various systems integrate in the release process:

GitHub tags & pre-releases
Homebrew tap
install.sh (this implies AWS S3 & CloudFront)
install.ps (we are deferring this towards the end)

Let me know if you think differently.

Yes I agree. It can and should happen in parallel.

OK, I understand the purpose of exec better now - the updated table in the description helps!
It may not be a big deal, but I liked dagger engine from the story perspective and dagger do from the v0.2 familiarity perspective. Having said that, we should either pick noun verb (e.g. dagger do) or noun scope (e.g. dagger engine) and remain consistent throughout.
I would really like us to standardise on the dagger <SUBCOMMAND> pattern and always require a subcommand, regardless whether this is a noun or scope. It will make shell completion easier and it will help everyone navigate the domain better. FTR https://clig.dev/#subcommands

Reminder to self: when dagger dev gets replaced with dagger gateway (or any other subcommand for that matter), remember to follow-up on:

https://github.com/dagger/dagger/pull/3310
https://github.com/dagger/dagger/pull/3285

Update to present two very different design options:

Option 1: all-in-one binary (same as before)
Option 2: client only (feedback welcome)

FYI @gerhard @sipsma @kpenfound

Given bikeshedding is welcome here, I am bringing some paint...
Option 1 makes more sense to me (with some changes): it's confusing to talk about a gateway or a worker. IMO they are part of infrastructure and implementation of a dagger cluster. It's simpler to think about the CLI as a client + engine (the shim is an implementation detail of the engine). It's similar to how users perceive the Docker engine.

Given bikeshedding is welcome here, I am bringing some paint...
Option 1 makes more sense to me (with some changes): it's confusing to talk about a gateway or a worker.

That only leaves 50% of option 1 ;) What changes would you propose?

IMO [gateway and worker] are part of infrastructure and implementation of a dagger cluster

Note that gateway is on the client side (client helper for SDKs)

What are the advantages of Option 2? I guess it seems mostly arbitrary to me in terms of UX. If we go with Option 1, we still retain the option of also having an OCI image in the future (in which we'd just put the same binary that has everything) if we want to for whatever reason.
In terms of the concepts we explain, I guess in either option 1 or 2 we have to explain that there's a client and a worker, does it really make a difference whether they are bundled in the same binary or not? I'm asking genuinely, maybe that's something that creates confusion; my immediate biased impression is that it doesn't really make much of a difference.
The other factors are:

Engineering effort - I only see more work for Option 2 (could be missing something)
Packaging convenience - you mentioned something about Option 2 being preferable in terms of repelling repackaging/forking. I'm interested in more details there, I don't see at the moment how option 2 helps relative to option 1, but I truly have zero experience with any considerations around that sort of thing so I am ignorant.

What are the advantages of Option 2? I guess it seems mostly arbitrary to me in terms of UX.

First attempt at listing advantages (may not be exhaustive):

Less commands and flags in the CLI syntax: only what end users need
Easier to explain the architecture: client runs on the end user's machine; the engine runs on worker machines.
Smaller binary size. Always good, but made more valuable by also reducing SDK size
Less bundling gymnastics needed to package the engine and all its subcomponents. We are free to split it into individual binaries, or not, whatever makes our job easier. We can also change this over time, since individual binaries are considered private and not to be packaged separately.
Not distributing the engine as a single Linux binary makes it harder for Linux distros and their commercial backers to redistribute modified versions. This was a major source of fragmentation for Docker, and made the overall user experience worse (not to mention unnecessary drama)
It only makes sense to run the engine on OCI-capable systems. Standardizing on running the engine on an OCI runtime makes that requirement more explicit, and frees us of the burden of shipping an additional binary target that is redundant
Allows a gqurl-style client UI, which doesn't require subcommands. If we bundle several functions in the same binary, this creates pressure to follow CLI best practices and park the client in a dagger client sub-command (as proposed by @gerhard earlier in this thread) which would be cumbersome IMO

cc @vito

Less commands and flags in the CLI syntax: only what end users need

Allows a gqurl-style client UI, which doesn't require subcommands.

Smaller binary size. Always good, but made more valuable by also reducing SDK size

I see the points here. All else being equal, starting with as minimalistic cmds/flags as possible does give us the most long term flexibility.
Another thing I'm realizing is that the engineering effort difference between option 1 and 2 isn't necessarily very large in the immediate term. I was previously imagining that option 2 would mean we immediately need to start publishing and maintaining images in a registry, but I don't think it necessarily does (right?).
Even the first step @grouville took with embedding buildkit is actually only a tiny step away from option 2. The only difference is that he made the equivalent of dagger worker a hidden subcommand, whereas in option 2 it would be a separate main func. If we made that slight adjustment it actually fits what we're describing in option 2 pretty much exactly (it's just that the image is not pulled from a registry).

We of course can pull the image from a registry when we want to, it's just not an absolute hard requirement

So yeah, I'm actually okay with Option 2. I see the point about keeping the CLI interface minimal, and the costs of it relative to Option 1 are not really very large.

Some points:

When would I use the client? If it's just to send arbitrary GraphQL queries that seems like kind of an edge case in the grand scheme of things, and promoting that to something as important-sounding as the "dagger client" might mislead users into thinking it's the primary interface. I guess the Bash SDK would use this, but for everything else I'd expect to just use an SDK anyway. If it's really only the Bash SDK I wonder if it should literally just be the "Bash SDK"? :thinking:
dagger exec needs to correlate 1:1 with the worker, so I'd expect it to not be present on OS X, and for the client's local dagger exec to always be ignored. To be honest I wouldn't expect this command to be exposed to the user at all. Right now we build from source anyway, but if we wanted to bundle the binary we could just go:embed it and stream it over. And if we do that, we'll need to make sure it's really small so it can fit in a single gRPC message. I ran into this with Bass and had to use upx to shrink the shim at some point. I guess alternatively we could unpack it to a LocalDir.
I think if we call it exec people will probably think it's used like docker exec and kubectl exec etc. I think shim would be clearer.
Distributing the worker as an OCI image allows us to have a 1:1 pairing of the worker + its shim for each architecture in a multi-architecture image, which feels really clean to me. But I think users will still want to be able to run it outside of an OCI runtime[^1], so I'd lean towards having an all-in-one binary for the worker even if we do this.
I know we talked about Concourse being a single binary sometime in the past (I forget which discussion), but I'll clarify that even Concourse had a separate client binary (fly) - it only bundled the different types of servers together (web and worker).

[^1]: e.g. to avoid nesting containers, which is as far as I can tell is totally fine but people seem to think there are ghosts there all the time

I just realized that we may want somewhere to put all the service tty debugger attachment stuff too (and other service socket types in the future). It may make sense to integrate it with the client command in that it works by first sending a graphql query for a websocket endpoint. Could be that if you send a query that selects a socket endpoint and provide an extra flag like --attach, it will attach you to it.

Many details to figure out there (how do you know what type of data you're attaching to), corner cases where you select more than one scalar, etc. etc. Just a rough idea

I have considered both options carefully and I think Option 1 (all in one binary) would be the simplest one and best if paired with the following elements from Option 1:

make the worker command invisible to end users 👻
distribute the binary as a OCI too

The above approach doesn't close the door to Option 2 as a future refinement. We could make the CLI smaller and the OCI more single-purpose, but just as I imagine that having the engine locally as a hidden feature will be incredibly useful (especially for those that run on Linux), so I think that having the CLI baked in the OCI will be useful for debugging purposes. Ephemeral containers are a great idea, but in practice they are not as convenient as having the tooling already in-place. This might also give us the option of launching an "enterprise" version at some point in the future which is stripped down. The focus is on "some point in the future".
For the next few weeks, I propose that we focus on the simplest thing. For me, that is the single binary distributed as an OCI too.

p.s.: My favourite Concourse feature was the single binary approach which could be run in web or worker modes. The binary also included the flyctl client which could be used by older flyctl clients to update themselves to the version that matched the web API. 🤯

I have considered both options carefully and I think that Option 1 (all in one binary) would be the simplest one and best if paired with the following elements from Option 2:

Care to elaborate on what ways it would be simpler? It would useful to have more detail to inform the final decision.

The above approach doesn't close the door to Option 2 as a future refinement. As a follow-up, we could make the CLI smaller and the OCI more single-purpose.

I don't see how that would happen. The inertia and bikeshedding is already enormous before launching. Imagine after we have actual users and a mature packaging process in place, then we propose changing the definition of the CLI, its role in the architecture, break some commands. It would not be impossible to switch to option 2 later in theory, but it would be so painful that we should assume it will be impossible in practice.

I imagine that having the engine locally as a hidden feature will be incredibly useful (especially for those that run on Linux).

What would be incredibly useful about it?

I also think that having the CLI baked into the OCI will be useful for debugging purposes.

That I agree with, 100%.

Some points:

When would I use the client? If it's just to send arbitrary GraphQL queries that seems like kind of an edge case in the grand scheme of things, and promoting that to something as important-sounding as the "dagger client" might mislead users into thinking it's the primary interface. I guess the Bash SDK would use this, but for everything else I'd expect to just use an SDK anyway. If it's really only the Bash SDK I wonder if it should literally just be the "Bash SDK"? 🤔 (Ok I guess it's also fish/zsh SDK. Shell SDK?)

I think instead of calling it "the client" we would just call it "the Dagger CLI". It would be the preferred way to interact with Dagger from a command-line environment (interactive or scripted). I think the Bash SDK, if we ever ship it, would be built on top of the CLI with additional bash-specific sugar.
In addition to sending arbitrary GraphQL queries, the CLI would also:

Auto-install engines using pluggable provisioners. Probably not something you'd use in production, but awesome for "zero-to-one" experience locally.
Other engine management commands. Rough equivalent of docker machine or buildx node management.
Namespacing / project management. Whatever solution we find to that problem, will probably hook into the CLI
Interactions with Dagger Cloud. Starting with login, but possibly others in the future
Dev tooling. We removed codegen, but it will come back... The CLI is the natural place to add it. There may be others in the future (hooks for testing maybe?)

An interesting comparison: Stripe presents "Stripe CLI" as an option in the API docs drop-down, alongside the language selection:

dagger exec needs to correlate 1:1 with the worker, so I'd expect it to not be present on OS X, and for the client's local dagger exec to always be ignored. To be honest I wouldn't expect this command to be exposed to the user at all. Right now we build from source anyway, but if we wanted to bundle the binary we could just go:embed it and stream it over. And if we do that, we'll need to make sure it's really small so it can fit in a single gRPC message. I ran into this with Bass and had to use upx to shrink the shim at some point. I guess alternatively we could unpack it to a LocalDir.
I think if we call it exec people will probably think it's used like docker exec and kubectl exec etc. I think shim would be clearer.

Yes I agree. dagger exec is confusing. That subcommand should either be renamed + hidden, or not present in the CLI at all.

Distributing the worker as an OCI image allows us to have a 1:1 pairing of the worker + its shim for each architecture in a multi-architecture image, which feels really clean to me. But I think users will still want to be able to run it outside of an OCI runtime1, so I'd lean towards having an all-in-one binary for the worker even if we do this.

Could we not make that an add-on option for later? Clearly it's not the primary use case, since today the huge majority of users run the "engine" (buildkit) in an OCI image, the alternative is barely documented and nobody seems to complain.
If we're going to eventually support both, it makes more sense to me to start with OCI as the mainstream, and later maybe add standalone binary as the niche option.

OK, let me try an option 3 which would be a hybrid of 1 and 2 with some of the feedback here incorporated.
I think we all agree on choosing the simplest option (for us and for users) but disagreement on what is and isn't simple :)

@gerhard @mircubed I'm afraid this is a blocker for the 0.3.0-alpha.1 release after all, since it affects what it is exactly that we will be releasing. We don't need to resolve 100% of this issue to unblock the release - but we need to resolve parts of it. Can you hold the release until we explicitly resolve that issue here?
Thanks

In the interest of getting this moving in a direction, I don't have any other objections and don't feel the need to expand on any of the points that I have made above.
I am perceiving a consensus forming around an OCI. Regardless what we put in it, our release process should be able to produce one. I will be adding this capability shortly.
As a starting point, the OCI will include the existing binary - go build ./dagger/cmd. I expect us to refine as necessary. The outcome of this issue will be important. I don't mind which way we decide is forward as long as we are moving again.

@marcosnils I would release both the engine & the CLI in lock-step for now. Once both hit 1.0 we should revise this. Until then, I foresee unnecessary cycles spent on compatibility discussions & breaking changes. FWIW, this is the same approach that Concourse used, and it worked well from my end-user perspective cc @vito.
Today we release everything from the same repository (this one). The only exception is the Go SDK since the repo is the package. I propose that we continue with this aproach, otherwise our automation will spread and we will be forced to open multiple PRs, across multiple repositories, for the same changes.
The other reason for keeping a single repo is that we publish to various destinations: PyPI, NPM, container registries, etc. The tags are there for our convenience - single source of truth - but most of our users should come via their package source, and not via this repository.

we just had a quick sync between @aluzzardi and @gerhard and agreed on keeping the CLI and the engine withing the same bundle and release process for the moment since it simplifies the implementation and given the fast release cadence that we will have in the upcoming months, dealing with separate distributions doesn't make sense now.

we just had a quick sync between @aluzzardi and @gerhard and agreed on keeping the CLI and the engine withing the same bundle and release process for the moment since it simplifies the implementation and given the fast release cadence that we will have in the upcoming months, dealing with separate distributions doesn't make sense now.

Makes sense. From an end-user perspective, it makes sense to make the CLI the "primary". So if you see a release called "0.4.2" on github and look at its contents, the primary thing you should see is the Dagger CLI. Since SDKs are primarily released elsewhere, and the engine can't be used on its own today (and when it is, it will be as a separate OCI image)


feature-wip Support joining tables with views

Proposed changes
Issue Number: close #xxx
Problem summary
Currently, some errors occur when we create a materialized view with multiple tables which include a inline view. We should support these scenarios.
Checklist(Required)

[ ] Does it affect the original behavior
[x] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.12 seconds
stream load tsv:          452 seconds loaded<PHONE_NUMBER>9 Bytes, about 157 MB/s
stream load json:         25 seconds loaded<PHONE_NUMBER> Bytes, about 89 MB/s
stream load orc:          73 seconds loaded<PHONE_NUMBER> Bytes, about 14 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230322142905_clickbench_pr_118935.html


Last minute fixes

Several last-minute fixes for custom DB edge cases:

Filter output of findDatabasesByIds to not include nulls. Previous behavior would return an array with nulls, and the Dataset.databases resolver would return them, causing a validation error. The alternate solution would be to change the findDatabasesByIds return type to include nulls, and handle the nulls at every caller. However, I felt most callers were built under the assumption that hidden databases just weren't returned, so I think filtering in findDatabasesByIds is the expected behavior.
Filter ds._source.annotation_counts correctly (my previous ?? [] fix would have broken it - I made that thinking I was changing a .map, not a .filter). And exclude DBs not visible to the current user.
Remove logger.error when a database can't be found in ds._source.annotation_counts. I don't think these deliver value as we don't normally monitor the logs. It was easier to remove it than factor in the possibility that no data was found due to hidden DBs (which is an edge cases that only happens when HMDB-v4 is somehow excluded/private)
Fix if (databaseId != null) { codepath. If databaseId was null due to having no visible annotation count records, this would have returned an invalid object with null databaseId/dbName fields, failing schema validation. Now it returns a null value instead of an object with null fields.
Unrelated fix: Make the currentUser prop in DatasetItemActions.vue optional, because Vue was logging console warnings as it's null when not logged in. My bad for not testing this case in my PR.

Added two more fixes:

Allow FDR values above 1.0. Previous discussion. It looks like analysis_version==1 defaults FDRs to 1.0 if they don't match any of the pre-defined levels. analysis_version==2 doesn't discretize FDR values, so values above 1.0 are possible, though uncommon.
Fixed an error when reprocessing datasets without changing the databases. In these cases, doc['moldb_ids'] was not defined.


Command to run E2E model of NER directly/only by speech model?

Hi, I have seen the readme of NER in https://github.com/he159ok/slue-toolkit
But I do not see a command to run a NER model directly/only by the speech model.
May I know a command to run it?

I have found it. Thanks~
I forget it is in the readme file of the root folder.
Sorry for the confusion.


AVRO-3892: [Rust] Support to resolve fixed from bytes and deserialize bytes in deserialize_any

What is the purpose of the change
(For example: This pull request improves file read performance by buffering data, fixing AVRO-XXXX.)
fixing AVRO-3892
This PR:

support to resolve fixed from bytes
support to deserialize bytes, fixed, decimal in deserialize_any

Verifying this change

For resolving fixed from bytes, I have add related test.
For deserializing bytes, fixed, decimal in deserialize_any, seems it don't have test for deserialize_any. If it required, we can consider to add test for whole deserialize_any. And actually I have test it in https://github.com/apache/iceberg-rust/pull/82 locally.

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Thank you, @ZENOTME !


Line through text in print reciept

How to write line through text in print ? Anyone ?

I think you can use escpos to do that


chore: add debugging for failing test case, see COUCHDB-3413

Overview
Add test case to see what trips up this test case in COUCHDB 3413.
I assume it is one where the cluster returns a 500 error.

Testing recommendations

This needs to run in CI for a bit until it pops up again.
JIRA issue number

https://issues.apache.org/jira/browse/COUCHDB-3413
Checklist

[x] Code is written and works correctly;
[x] Changes are covered by tests;
[x] Documentation reflects the changes;
[x] I will not forget to update rebar.config.script
with the correct commit hash once this PR get merged.

+1
At first I was about to mention that EUnit captures and hides all the stdout output but then noticed we send output directly to console with user in io:format. So that should work. However in general ?debugFmt is the recommended way to print during EUnit tests.  Not big deal though just a minor nit.

re debugFmt same as in https://github.com/apache/couchdb/pull/517#issuecomment-301570471

Alright, let's go with user then, minor nit anyway


Add Windows container image for PowerShell Core

On the Docker Hub, there are automated builds for Linux container images, however there's no container image to run PowerShell Core on the Windows platform. We should provide a new container image tag for microsoft/powershell:nano, or similar.

Cheers,
Trevor Sullivan
Docker Captain
Microsoft MVP: Cloud & Data Center Management
https://trevorsullivan.net
https://twitter.com/pcgeek86

I thought https://github.com/PowerShell/PowerShell/pull/2495 addressed this?  @brycem

Correct - We have Dockerfiles to install the current Powershell release here:  https://github.com/PowerShell/PowerShell/tree/master/docker/release.  No nightly\daily build support yet.

@brycem are you working on getting nightly/daily build support?

Before I I left on vacation, @raghushantha and I were blocked on a Win10Sdk bug.  Looks like they may have a private fix to take a look at.  Have you done this already Raghu?

Images are up:

@TravisEz13, @raghushantha  - The Jenkins deployment would be an easy place to automate the build process for these images going forward:  https://azopenci.westcentralus.cloudapp.azure.com/

@brycem The build is already automated.  Let's please discuss this offline.


Check if and how it is possible to switch Go module names to a domain <> the GitHub domain the module code resides on

What would you like to be added:
We have all Golang modules named like the github repository name they reside in, e.g. ocm.software/open-component-model/ocm.
Now we want to restructure the modules and during the same activity also change the name of the modules to a different domain than the code repository resides on. The new domain should be "ocm.software", so that the new Golang module would be named "ocm.software/open-component-model/ocm".
How can this be achieved and what needs to be done on the server serving requests for "ocm.software" to redirect requests from Go clients that want to use the module ocm.software/open-component-model/ocm to the correct location on the github repository ocm.software/open-component-model/ocm ?
Epic link: #655
**Possible solution:
Set up a custom domain for your Go modules and configure the server to redirect requests to the correct location on the GitHub repository.
Here are the steps:

Change the module path in your Go files: Update the import paths in your Go files to use the new domain. For example, change import "github.com/ocm.software/open-component-model/ocm" to import "ocm.software/open-component-model/ocm".

Update go.mod file: Change the module directive in your go.mod file to reflect the new domain. For example, module github.com/ocm.software/open-component-model/ocm should be changed to module ocm.software/open-component-model/ocm.

Configure the server for ocm.software: You need to set up your server to respond with HTML meta tags that point to the new location of your Go module. When the Go command fetches a package by path, it does so through a series of HTTP requests. It first requests the import path as a URL with the go-get=1 query parameter. The server should respond with a meta tag in the HTML body of the response that specifies the source repository of the package.

Here is an example of how the meta tag should look:
    <meta name="go-import" content="ocm.software/open-component-model/ocm git https://github.com/ocm.software/open-component-model/ocm">

This meta tag tells the Go command that the package ocm.software/open-component-model/ocm is a git repository located at https://github.com/ocm.software/open-component-model/ocm.

Test the setup: You can test if everything is set up correctly by running go get ocm.software/open-component-model/ocm@version, where version is the version of your module. If everything is set up correctly, the Go command should be able to find and download your module.

For more information, refer to
Official Go documentation on [Custom Import Path(https://golang.org/doc/go1.4#canonicalimports) and Go Modules.
go.devgo.dev on Using Go Modules - The Go Programming Language
An introduction to the basic operations needed to get started with Go modules.

<html><head>
                  <meta name="go-import"
                        content="k8s.io/kubernetes
                                 git https://github.com/kubernetes/kubernetes">
                  <meta name="go-source"
                        content="k8s.io/kubernetes
                                 https://github.com/kubernetes/kubernetes
                                 [https://github.com/kubernetes/kubernetes/tree/master{/dir}](https://github.com/kubernetes/kubernetes/tree/master%7B/dir%7D)
                                 [https://github.com/kubernetes/kubernetes/blob/master{/dir}/{file}#L{line}](https://github.com/kubernetes/kubernetes/blob/master%7B/dir%7D/%7Bfile%7D#L{line})">
            </head></html>


[Enhancement] Start debugging with sudo

Description
I would be very nice to be able to start the debugging session with sudo when developing software that need to be run with admin rights. Often that ise the case when developing systemd services.
Right now I have to use the build and deploy and the use the DebugAdapterHost.Launch manually from the command window to do that. The only thing different from the generated launch.json and my manually written launch.json that works is the adapter args.
Generated: -ssh -pw password user@host -T  ~/vsdbg/vs2022/vsdbg  --engineLogging=./VSLinuxDbg/Application/_vsdbg.log
Needed: -ssh -pw password user@host -batch -T sudo ~/vsdbg/vs2022/vsdbg  --engineLogging=./VSLinuxDbg/Application/_vsdbg.log
It would be nice to implement an option for this.

There aren't any plans to include sudo just yet. However, don't be discouraged, your suggested feature may appear in a future release once the advanced settings dialog that will be implemented in the near future.
Until then, I suggest that your application execute elevated procedures when necessary versus the entire application if possible. I can dig up a sample of this if you'd like.


Fix/mode adapter error

This PR addresses the added robot mode MODE_ADAPTER_ERROR that is defined here. The fixes have tested it in simulation with instructions to recreate below. These fixes are quick and dirty, and will be reworked in a better manner during the full re-write of Free Fleet that is underway.

Added handling of MODE_ADAPTER_ERROR, in the domain of Free Fleet, it is named MODE_REQUEST_ERROR as there is no information about adapters yet
When first waypoint of a path request is too far away (distance more than max_dist_to_first_waypoint in configuration), MODE_REQUEST_ERROR will be triggered, and robot will be commanded to stay put and wait for next valid request
cleaned up client's logging, only when warnings arises, eg. first waypoint of path command too far

Test
Prepare the ROS1 and ROS2 workspaces according to instructions from the README, be sure the checkout this branch before building each workspace, and the develop branch of rmf_core for the ROS2 workspace.
Launch the multi-turtlebot3 simulation from the ROS1 workspace,
source ~/client_ws/devel/setup.bash
export TURTLEBOT3_MODEL=burger; roslaunch ff_examples_ros1 multi_turtlebot3_ff.launch

Launch the server from the ROS2 workspace, it should register all 3 robots in simulation as clients,
source ~/server_ws/install/setup.bash
ros2 launch ff_examples_ros2 turtlebot3_world_ff.launch.xml

Send a path request that has its first waypoint too far from the bottom-most turtlebot3, tb3_0,
source ~/server_ws/install/setup.bash
ros2 run ff_examples_ros2 send_path_request.py \
    -f turtlebot3 -r tb3_0 -i random_id \
    -p '[{"x": 5.9149, "y": -4.046, "yaw": 0.0, "level_name": ""}, {"x": 6.611, "y": -2.685, "yaw": 0.0, "level_name": ""}]'

On the ROS1 terminal, you should see a warning that the distance is too far, while the robot in simulation doesn't move.
Check the robot's mode using ros2 topic echo /fleet_states, the robot tb3_0's mode should now be 8, which corresponds to MODE_ADAPTER_ERROR.
Now, send a valid path request that is within reach to the same robot,
source ~/server_ws/install/setup.bash
ros2 run ff_examples_ros2 send_path_request.py \
    -f turtlebot3 -r tb3_0 -i another_random_id \
    -p '[{"x": -6.10281848907, "y": 2.64789390564, "yaw": 0.0, "level_name": ""}, {"x": -4.11846208572, "y": 1.303637743, "yaw": 0.0, "level_name": ""}]'

The request should be received by the client, the robot should start navigating to the first waypoint in the request, while its mode should not be 8 anymore

yup! I don't think a merge is a good idea at this point, rather this branch should be kept open if we really need that adapter error


Migration to TypeScript?

Interested in migrating your code to TypeScript? I want to contribute.

Thank you very much, but we have to decline. We find JS leads to more contributions.


Dose it support raspignss nmea meassge?

Hi.
I've installed setup raspignss module that uses NV08C. (http://drfasching.com/products/discontinued/raspignss-cook/installation.html)
Attached file is nmea message after sending 'nmeaparsing' command on the host. Can nmea_navsat_driver be used in raspignss module?

If your device outputs the standard NMEA sentences GPGGA or GPRMC, you can use it with this driver.


tensorflow error issue python3.8.1

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import tensorflow
  File "C:\Users\mark scorp lezeret\AppData\Local\Programs\Python\Python38-32\lib\site-packages\tensorflow\__init__.py", line 24, in <module>
    from tensorflow.python import pywrap_tensorflow  # pylint: disable=unused-import
  File "C:\Users\mark scorp lezeret\AppData\Local\Programs\Python\Python38-32\lib\site-packages\tensorflow\python\__init__.py", line 49, in <module>
    from tensorflow.python import pywrap_tensorflow
  File "C:\Users\mark scorp lezeret\AppData\Local\Programs\Python\Python38-32\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 58, in <module>
    from tensorflow.python.pywrap_tensorflow_internal import *
  File "C:\Users\mark scorp lezeret\AppData\Local\Programs\Python\Python38-32\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 114
    def TFE_ContextOptionsSetAsync(arg1, async):
                                         ^
SyntaxError: invalid syntax

Please fill in template. Note that we don't yet release python 3.8 pip packages.

It dosent work in anny pc or visjoner og python dear boy!

Dont work on anny visjoner of python anny tips

We also don't release pips for 32 bits systems.
Without a proper issue template being filled in, we can't know how to progress.

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

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


[CLI]: Repord Editing API does not create a valid report

Describe the bug
Hello, I used python sdk API to create a report in https://wandb.ai/costa-huang/cleanRL/reports/Atari-CleanRL-PPO-gym-vs-envpool--VmlldzoyODg0NzU2, but it cannot display the lines between two groups properly. The issue is rather weird — the following video demonstrates it
https://user-images.githubusercontent.com/5555347/199073850-a805b4a3-7219-497d-bc9b-ed584535f20f.mov
A couple of notes / bugs:

Only the group of runs in CleanRL's ddpg_continuous_action_jax (v1.0.0b2-9-g4605546) displays correctly but not the group of runs in CleanRL's ddpg_continuous_action_jax (latest).
The group of runs in CleanRL's ddpg_continuous_action_jax (v1.0.0b2-9-g4605546) is being displayed twice (both the dotted and solid lines)
When trying to edit the filter through the App UI, the site crashed with the error Error 1054: Unknown column 'tags' in 'field list'
By manually cloning the two run sets using the App UI the runs are somehow displayed correctly... Not sure why.

CC @andrewtruong (thanks for the programmatic API for report editing — it's of great help).

from typing import List
import wandb
import wandb.apis.reports as wb  # noqa
wandb.require("report-editing")
api = wandb.Api()

class Runset:
    def __init__(self, name: str, filters: dict, entity: str, project: str, groupby: str = ""):
        self.name = name
        self.filters = filters
        self.entity = entity
        self.project = project
        self.groupby = groupby

    @property
    def runs(self):
        return wandb.Api().runs(path=f"{self.entity}/{self.project}", filters=self.filters)

    @property
    def report_runset(self):
        return wb.RunSet(
            name=self.name,
            entity=self.entity,
            project=self.project,
            filters={"$or": [self.filters]},
            groupby=[self.groupby] if len(self.groupby) > 0 else None,
        )

def compare(
    runsets1: List[Runset],
    runsets2: List[Runset],
    env_ids: List[str],
):
    blocks = []
    for runset1, runset2, env_id in zip(runsets1, runsets2, env_ids):
        blocks += [
            wb.PanelGrid(
                runsets=[
                    runset1.report_runset,
                    runset2.report_runset,
                ],
                panels=[
                    wb.LinePlot(
                        x="global_step",
                        y=["charts/episodic_return"],
                        title=env_id,
                        title_x="Steps",
                        title_y="Episodic Return",
                        max_runs_to_show=100,
                        smoothing_factor=0.8,
                        groupby_rangefunc="stderr",
                        legend_template="${runsetName}",
                    ),
                    wb.LinePlot(
                        x="_runtime",
                        y=["charts/episodic_return"],
                        title=env_id,
                        title_y="Episodic Return",
                        max_runs_to_show=100,
                        smoothing_factor=0.8,
                        groupby_rangefunc="stderr",
                        legend_template="${runsetName}",
                    ),
                    # wb.MediaBrowser(
                    #     num_columns=2,
                    #     media_keys="videos",
                    # ),
                ],
            ),
        ]
    return blocks

if __name__ == "__main__":
    env_ids = ["Hopper-v2", "Walker2d-v2", "HalfCheetah-v2"]

    blocks = []
    runsets1 = [Runset(
        name="CleanRL's ddpg_continuous_action_jax (v1.0.0b2-9-g4605546)",
        filters={"$and": [
            {"config.env_id.value": env_id},
            {"tags": "v1.0.0b2-9-g4605546"},
            {"config.exp_name.value": "ddpg_continuous_action_jax"}
        ]},
        entity="openrlbenchmark",
        project="cleanrl",
        groupby="exp_name",
    ) for env_id in env_ids]
    runsets2 = [Runset(
        name="CleanRL's ddpg_continuous_action_jax (latest)",
        filters={"$and": [
            {"config.env_id.value": env_id},
            {"tags": "latest"},
            {"config.exp_name.value": "ddpg_continuous_action_jax"}
        ]},
        entity="openrlbenchmark",
        project="cleanrl",
        groupby="exp_name",
    ) for env_id in env_ids]

    blocks = compare(runsets1, runsets2, env_ids)
    print("saving report")
    report = wb.Report(
        project="cleanrl",
        title="Regression report",
        blocks=blocks,
    )
    report.save()
    print(f"view the generated report at {report.url}")

(cleanrl-py3.7) ➜  cleanrl_utils git:(rlops) ✗ python minmal_bug.py
wandb: WARNING This is an experimental feature -- use with caution!
saving report
view the generated report at https://wandb.ai//costa-huang/cleanRL/reports/Atari%3A-CleanRL-PPO-gym-vs-envpool--VmlldzoyODg0NzU2

Additional Files
No response
Environment
WandB version: 0.13.4
OS: Ubuntu
Python version: 3.7.1
Versions of relevant libraries:
Additional Context
No response

Thank you @vwxyzjn for providing a link to the report and video demonstrating the issue you are running into. We will review and provide feedback by EOW.

Hi @vwxyzjn , brief update on this issue. I performed a preliminary review and noticed a differences between filter values referenced in your script and what was actually logged to your project.
When I clicked the filter icon, I also crashed but was able to capture which field/values are set. Those values correspond to the values assigned by your filters={...} dictionary in your script.
From your runs tables, I could not identify a set of runs that filter down per those specific filter/value. I believe the discrepancy and irregularities of the charts originates from this. I will attempt to reproduce with the api Script and get back to you with my findings.

Interesting. So it looks like the filter is tags whereas through the web UI you need to say Tags (where the first letter is capitalized). Also the operator is =, whereas the available options for Tags are is, is not, in, not in

Hi @vwxyzjn , thank you for the additional insight. We will be releasing a new version of the reports API that expands on functionality and will address some of these additional checks to prevent similar issue from happening again. I will update you and provide reference links to the new API when available.

Hi @vwxyzjn, quick update, the new version of the reports API is expected to be released with our next client version and includes additional fixes/features to address some of the issues you ran into.


Remove: vim.vim version 8.2.4478

## .\Tools\YamlCreate.ps1 -PackageIdentifier vim.vim -Mode 5 -SkipPRCheck -PackageVersion 8.2.4478

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

/azp run


[Release][Docs][GLib] Use Sphinx based GLib front page

Describe the enhancement requested
GH-40441 migrated GLib front page from apache/arrow-site to Sphinx but our release script still uses apache/arrow-site's one.
Component(s)
Documentation, GLib, Release

The GLib front page: https://arrow.apache.org/docs/c_glib/

Issue resolved by pull request 41406
https://github.com/apache/arrow/pull/41406

@github-actions crossbow submit test-conda-python-3.10-spark-v3.5.0

@github-actions crossbow submit test-conda-python-3.10-spark-v3.5.0


System Info not show

After last commit not show System Info

What's in /var/log/syslog?

Feb 17 16:00:53 ir3ef python3[14986]: 2021-02-17 16:00:53,214 INFO Closed, remote=('<IP_ADDRESS>', 62353), path=/SYSINFO, exception=[Errno 13] Permission denied: '/tmp/mmdvm-version'
it is strange, I have 5 repeaters, 4 work fine and only one from this error. Before the commit they all worked

This seems to be a filesystem-problem with permissions for user "mmdvm"...
please check permission for /tmp-folder, maybe you should set chmod ugo+rw
/tmp so that every user can write to /tmp what is intended by nature of
this folder...
73

/tmp folder has 1777 properties

Do you have an read-only-overlay or something running at this installation?
I am wondering why the user can't write to this file... is it existing?
What does a ls -la /tmp/mmdvm-version show?
Otherwise: Did you put the user mmdvm as told in the readme.md into the
dialout-group? Think it is the problem that this installation the user
can't write/read from serial...

After reboot (I did not think about it) problem solved...
all work fine
73

Thank you - will close the issue then...
73 de Kim


Deploy Svelte and Supabase to Google cloud and supabase is unable to get the environment variables

What I expected to happen
I’m trying to use gcloud command line to deploy and sveltekit web app with supabase. I expected the build to complete successfully and be able to host my app on google cloud.
I have run the following command to deploy gcloud run deploy --update-env-vars SUPABASE_URL=<supabae_url>,SUPABASE_ANON_KEY=<supabase_anon_key>
Here a link to my repo https://github.com/ming-060211/DeploymentError
What happened instead
The docker build is failing at the stage “npm run build” with the following error,
`Step 6/15 : RUN npm run build
---> Running in 9ea98b1abb71

<EMAIL_ADDRESS>build
vite build

vite v5.1.3 building SSR bundle for production...
transforming...
✓ 82 modules transformed.
rendering chunks...
THis is supaurl  undefined
node:internal/event_target:1062
process.nextTick(() => { throw err; });
^
Error: supabaseUrl is required.
at new SupabaseClient (/app/node_modules/@supabase/supabase-js/dist/main/SupabaseClient.js:43:19)
at createClient (/app/node_modules/@supabase/supabase-js/dist/main/index.js:35:12)
at file:///app/.svelte-kit/output/server/entries/pages/_page.server.js:7:18
at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:336:24)
at async Promise.all (index 2)
at async analyse (file:///app/node_modules/@sveltejs/kit/src/core/postbuild/analyse.js:66:16)
at async MessagePort. (file:///app/node_modules/@sveltejs/kit/src/utils/fork.js:22:16)
Emitted 'error' event on Worker instance at:
at [kOnErrorMessage] (node:internal/worker:314:10)
at [kOnMessage] (node:internal/worker:325:37)
at MessagePort. (node:internal/worker:225:57)
at [nodejs.internal.kHybridDispatch] (node:internal/event_target:786:20)
at exports.emitMessage (node:internal/per_context/messageport:23:28)
Node.js v18.19.1`
What I’ve tried to do to fix it
I added the env variable to the gcloud run deploy with –update-env-vars url=asdfasdf and I printed the env var to a test page. This works so the env var is available when the app is running.
I’ve also hardcoded the supabase url and anon key, and the deployment works, but I can’t do this with production code.
What I think might be wrong
The npm run build is failing because gcloud run deploy makes the env vars available during run time but they are not available during the docker build. For some reason supabase needs these vars during build and it’s failing.

Answer:
changed Dockerfile to take in build args in build and execution stages used gcloud builds submit with --substitutions flag to build image with required env vars used gcloud run deploy with --image flag pointing to previously built image
Example Updated on Repo


Need to support Vue3

I'm working on a project with Vue3 (+Router 4 + Quasar 2) and tried to use this library and get the error

I guess it is because the library doesn't support Vue3.
If it's correct, please upgrade it.
Thanks a lot

@voquanghoa Thanks a lot for reporting the issue. Sorry I was recently not really active on the project, but I'm gonna deploy a new version with the next weeks!

Awesome plugin, but I got the same issue. Nice to know that a new version is coming up!

@Orlandster it would be great to have support for Vue 3.


Add Speech-To-Text commands for (mostly) hands-free play

After trying this great app (thanks for making it open source) I was thinking this would be an amazing activity for long commutes or other activities where looking at/tapping on your device would be unwise. Is this something on the roadmap or has had any work been done to this end? If not, I may look into adding it if it would be merged in.

Am 26.12.2018 20:26, schrieb Brendan LaMarche:

After trying this great app (thanks for making it open source) I was
thinking this would be an amazing activity for long commutes or other
activities where looking at/tapping on your device would be unwise. Is
this something on the roadmap or has had any work been done to this
end? If not, I may look into adding it if it would be merged in.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/onyxbits/TextFiction/issues/30, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAbpgRI4ccFC-3VRtvjBkr5cNvSoinTDks5u881UgaJpZM4ZiBqo.

There are no plans for adding this as voice recognition can't be done
(well) on the device itself (at least not on older devices). I also
don't feel well about requesting microphone and network permission in
order to ship your audio data over to Google or Amazon.
Have you tried installing a voice enabled keyboard?

Out of curiosity, is that because of privacy concerns or battery/network usage? From my viewpoint, the privacy ship has sailed years ago.
I like the idea, but you'd have to flag a large area to the main screen to turn recognition on or off for a commute. I suspect that leaving it on constantly would drain the battery quickly as well as using up network bandwidth. Actually, you might be able to capture the button on a bluetooth headset to toggle the mic on and off with an inactivity timer.
My 2c,
Ralph

It seems you are determined to shut this down, as you keep coming up with new reasons. Its your project, so do as you will, but can you really not think of other use cases?
How about for the vision or mobility impaired? The TTS is a good first step, but that doesn't help someone type easily and those voice keyboards don't have ease of use the advantage of app integration would provide (like I said, to be able to correct commands based on contents of previous descriptions, auto-listen for next command, etc).
I guess the only option then is to fork and make a separate app? That'd be a real shame.
PS: Voice command is one of the safest machine-interaction methods for drivers on the road. Far better than those touch-screen controls they are slapping into every vehicle console these days. With voice command, this app wouldn't be significantly more distracting than an audio book or podcast.

Am 27.12.2018 18:56, schrieb Brendan LaMarche:

It seems you are determined to shut this down, as you keep coming up
with new reasons. Its your project, so do as you will, but can you
really not think of other use cases?

Let me put it this way, there are two things that are not going to happen:
a) Making TF dependant on any external service (especially not one that
requires API keys or is well known for privacy invasion). Since TF is
free, I don't earn the money to pay for an external service and I won't
let users pay with their privacy either.
b) Using a local, low quality VR engine that fails half of the time
and/or doesn't work out of the box (has to be trained by the user).
Since TF is freem there isn't any money for marketing beyond begging
users for reviews on Play. Having ratings tank because a feature doesn't
work as advertised is a no-go.

I guess the only option then is to fork and make a separate app?
That'd be a real shame.

Threatening a fork is not really a convincing argument. Showing a proof
of concept would be: make a (standalone) demo app, one activity screen
only (doesn't have to be fancy) that just listens to the user and prints
what it understood to a ListView. If that works reliably (under the
conditions mentioned above), we can talk.

I mean no ill will towards you or this project, thats for sure. As I said before, I am thankful this project is open source!
To do the proof of concept you state adequately and have the local text recognition be accurate enough it would be just as simple for me to add it into to the actual TextFiction source, since it'll need the context of the fiction text itself. On its own, a local recognizer won't be good enough.
When I get some time, I will likely add this STT feature. If you won't merge it in, it'll be a fork with a separate listing in the app store, simple as that. Its not a threat, just a statement of fact.


Flutter web implementation example docs

firestore-stripe-subscriptions

Hi ! In the extension documents in Firebase there is only example implementation for JavaScript.
I managed alone to translate the CreatePortalLink function to dart, but I am having trouble with CreateSession.
For anyone searching for CreatePortalLink implementation in dart, here it is.
Future<void> createCheckout() async {
    final HttpsCallable callable = FirebaseFunctions.instanceFor(region: 'europe-west3')
        .httpsCallable('ext-firestore-stripe-subscriptions-createPortalLink');
    var result = await callable.call(<String, dynamic>{
      'returnUrl': "https://project-name.web.app/#/"
    });
  }

And this is the CreateSession function in JavaScript.
const docRef = await db
  .collection('customers')
  .doc(currentUser.uid)
  .collection('checkout_sessions')
  .add({
    price: 'price_1GqIC8HYgolSBA35zoTTN2Zl',
    success_url: window.location.origin,
    cancel_url: window.location.origin,
  });
// Wait for the CheckoutSession to get attached by the extension
docRef.onSnapshot((snap) => {
  const { error, url } = snap.data();
  if (error) {
    // Show an error to your customer and
    // inspect your Cloud Function logs in the Firebase console.
    alert(`An error occured: ${error.message}`);
  }
  if (url) {
    // We have a Stripe Checkout URL, let's redirect.
    window.location.assign(url);
  }
});

What will the implementation for this be in dart / flutter ?

I tried to call the createCheckoutSession cloud function as the CreatePortalLink one,
    final HttpsCallable callable = functions.httpsCallable(
        'ext-firestore-stripe-subscriptions-createCheckoutSession');

    var result = await callable.call(<String, dynamic>{
      'returnUrl': "https://tokhub-1e14d.web.app/#/profile"
    });

    print(result.data);
  }```

 but I got an error '[firebase_functions/unauthenticated] unauthenticated', even though I am authenticated with OAuth, I even changed the permissions in the Firebase Database and the Google Cloud Console, still no

I tried to call the createCheckoutSession cloud function as the CreatePortalLink one,
Future<void> createCheckout() async {
    final HttpsCallable callable = functions.httpsCallable(
        'ext-firestore-stripe-subscriptions-createCheckoutSession');

    var result = await callable.call(<String, dynamic>{
      'returnUrl': "https://project-name.web.app/#/"
    });

    print(result.data);
  }

but I got an error '[firebase_functions/unauthenticated] unauthenticated', even though I am authenticated with OAuth, I even changed the permissions in the Firebase Database and the Google Cloud Console, still no


Add options resource attribute for chef_gem

Cookbook version
2.0.0
Scenario:
I'm trying to use this cookbook from behind a firewall. So, I need to ability to pass gem install options to the chef_gem resource. in my case, -p for http_proxy.
PR #57

Create a PR to fix this: https://github.com/chef-cookbooks/chef-vault/pull/57

This was merged, thanks.


IOS : RangeError: Maximum call stack size exceeded.

code:   core.pairing.pair({ uri: wcuri })
When pair to the dapp,an error was reported on IOS. Android is fine.
ERROR  {"context": "core"} {"context": "core/relayer"} [RangeError: Maximum call stack size exceeded.]
It seems that if the [walletconnect/core] package is v2.7.1, this error will be reported.

It happend even in sample wallet project.
https://github.com/WalletConnect/react-native-examples/tree/main/wallets/rn_cli_wallet_068_5

Any fix for this issue?

Please help for this issue, my wallet on iphone cannot connect with any dApps due to this

@DamperX the above solution can fix this issue, I have tried

Im closing this as is not happening in the latest versions of web3wallet + core.
Feel free to open a new one if you are able to reproduce it using the newest versions.


[WIP] Add filtering support

This is an initial implementation of the filtering criteria support in benchmarks. Right now only for Qdrant.

There is an additional commit for the pre-commit bot included, but the changes are mostly related to the new reader and Qdrant client.

@joein It's still in progress, however I'd appreciate your review on that.


Feature: Add filter for games with missing media files / show only games with media files

After scraping finished i got some games that were not found by the scraper. I would like to look them up but i would need to scroll through the whole database. It would be very convenient if there is a filter for hiding games with media or missing media.

Done.

Wow, that was a quick one. Thanks!


How to transfer data from dappchain to ethereum mainnet ?

I hava built my own dappchain by Loom sdk, but do not now how to exchange data between my dappchain   and ethereum.Should I do it with my own code?

Transfer Gateway is coming out fairly soon

@mattkanwisher thx


FILEUPLOAD-286: allow default charset to be overridden.

useful in cases where form-data is utf-8 encoded but
not encoding is not explicitly specified

Applied.

Applied, thank you!

@maxxedev Thanks for the pull request! It would be nice if you could close it, now that @jochenw has merged it. Thanks!

thanks for quck response and merge.
not sure what's going to what's going with builds for jdk6/7.
closing pull request anyways

@maxxedev Thanks!
The jdk6/7 build failures are unrelated. https://github.com/apache/commons-fileupload/pull/11 contains the fix for these failures.


[9.x] Add pivot default columns

Currently, loading columns for a Pivot class in a many-to-many relation requires manually adding all column names on the relation method. This is slightly confusing sometimes, and moreover leads to some code duplication if you want to query the same pivot columns from both sides of the relation.
This PR adds a withColumn property to the Pivot class, where one can mark columns that should be loaded on all relations referencing the pivot.
Alternative approaches:

use the attributes property, though this would require adding a default value for all columns
use the casts property, though this would require adding a cast-type for all columns

Instead of adding a new framework feature I typically just recommend people create a method that returns the columns. Then you can remove the code duplication:
return $this->belongsToMany(...)->with(PivotModel::defaultColumns());


Fix list_cpu_features.exe does not detect SSE42 on Xeon X5650 (Windows)

https://github.com/google/cpu_features/issues/200

I have a patch ready that embeds uarch detection inside X86Info. At first, I wanted to have it pushed before this one but I've already slowed you down enough. Let's submit this one as-is and I'll refactor it a bit afterwards.

Fixes #200


Querys that return large # of results can freeze / crash the app

I ran a query on local context that returned a large number of rows and the app became unresponsive after completing.  We need to paginate somehow

@alamb FYI pagination also relevant for local context

@alamb FYI pagination also relevant for local context

I agree
One way to do this might be to wrap the SendableRecordBatchStream in an object that buffers past results and fetches next result on demand. Something like this perhaps
struct @alamb FYI pagination also relevant for local context {
  // currently executing stream
  inner: SendableRecordBatchStream,
  // any batches that have been buffered so far
  batches: Vec<RecordBatch>,
  // current batch being shown
  current_batch: usize,
}

impl SendableRecordBatchStream {
  /// return the next batch in the stream
  async fn next(&self) -> &RecordBatch {
    self.current_batch += 1;
    self.current()
  }

  /// go to current_index
 async fn current(&self) -> &RecordBatch{
    while self.batches.len()+1 < current_batch {
      // fetch next batch from inner and put into self.batches
    }
    self.batches[self.current_batch]
}


Crash when requesting summary of hidden photo

🐛 Bug Report

[x] 📁 I've Included a ZIP file containing my librephotos log files
[x] ❌ I have looked for similar issues (including closed ones)
[x] 🎬 (If applicable) I've provided pictures or links to videos that clearly demonstrate the issue

📝 Description of issue:
When requesting the summary of a hidden photo, there is a crash on the backend (logs attached)
🔁 How can we reproduce it:
Request the /api/photos/{HASH}/summary/ endpoint for an image that is previouslyu hidden.
Please provide additional information:

💻 Operating system:  docker on ubuntu
⚙ Architecture (x86 or ARM):  x86
🔢 Librephotos version: dev
📸 Librephotos installation method (Docker, Kubernetes, .deb, etc.):

🐋 If Docker or Kubernets, provide docker-compose image tag: dev

📁 How is you picture library mounted (Local file system (Type), NFS, SMB, etc.):  local file systen

log.txt

Your are calling /api/albums/date/hiddenPhoto/, which is creating the subsequent error. This is not the correct format, when using this API. If you want to filter, for only hidden photos, use /api/albums/date/list/?hidden=true for getting all relevant album dates and /api/albums/date/67/?page=1&hidden=true for requesting a page with only hidden images. If you need additional information let me know :)


Remove stray space from consent screen disclaimer

As reported by Thijs, there is a stray space after "heeft deze informatie nodig om te kunnen werken" in the first item of the disclaimerlist.  It was caused by formatting of the code.  This PR removes that.

@Badlapje the Consent behat test seems to suffer from this change. I'm going to investigate my dear Watson!

Report: Behat tests are running on the old openconext theme. That is/was fine, but feature and text wise the themes are diverging more and more.
I'm going to update the Behat tests for them to run against the new theme. This will involve quite a bit of tinkering. I will isolate that change to a PR of my own. For now, please be very wary of what test fails and reason if your code change has anything to do with that. If this is not the case. For now ignore the acceptance tests and :shipit:


[sil] Make ValueOwnershipKind(unsigned) explicit to prevent implicit …

…casts from ints/bools to ValueOwnershipKind.
I hit this problem while splitting classifying operand ownership from the
ownership verifier itself. There is no reason to allow for this implicit
conversion. Just makes updating code more error prone.
rdar://44667493

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge


Trying to fix weird github actions error with protobuf version

@5A11 - I had to make a similar change on my local change. Think that we should try and land this ASAP

@MissingNO57 Is that the latest version that does not have the problem?

Mostly to help finding this later - got the tests failing as well with an error similar to:
E   TypeError: Descriptors cannot not be created directly.
E   If this call came from a _pb2.py file, your generated code is out of date and must be regenerated with protoc >= 3.19.0.
E   If you cannot immediately regenerate your protos, some other possible workarounds are:
E    1. Downgrade the protobuf package to 3.20.x or lower.
E    2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use pure-Python parsing and will be much slower).
E
E   More information: https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates

Installing the suggested version from this PR does fix it. Had to also change it from the  requirements.txt and requirements-dev.txt files to make the github actions happy.

This is now fixed in #66


More detailed description on image version?

What's the base image system?
What is the rootless container?
Explain?

The variants are Alpine and windowsservercore-1809
https://github.com/docker-library/docs/tree/master/docker#simple-tags
The rootless variant runs as a non-root user
https://github.com/docker-library/docs/tree/master/docker#rootless
For more information on it see the linked thread https://github.com/docker-library/docker/pull/174
In the future questions like these are better asked over at the Docker Community Forums, Docker Community Slack, or Stack Overflow. Since these repos aren't really a user-help forum

Thanks for the explanation but I think it's better to put in the repo markdown. This is more related to what things are than “user-help”.


Autocomplete dropdownOptions

So with select fields I can init with:
$('select').formSelect({     dropdownOptions:{       container: document.body,     }   });
which makes it so if the select is in a modal, it doesn't clip the dropdown/ affect the modal's size. Here's a screenshot of this working correctly:

When trying the same with autocomplete, the dropdownOptions option is ignored. Here is the init i am using:
$(this).autocomplete({         data: options_list,         dropdownOptions:{           container: document.body,         }       });
Which results in this:

How do we set the dropdown container for autocomplete elements?

@rmountjoy92 - a word of advice: modals are meant for small amounts of content, and you will run into trouble on some devices displaying lengthy complex content like this. What does this look and feel like on mobile? If you are in a situation where you need to scroll inside a modal, then you need to consider having the content displayed on a page in a standard way. Some touchscreen devices won't recognise the scroll at all. Sometimes simple is better. Sometimes boring is better!
That said, if you must use a modal in this way, you'll need to show a live example or code pen. It is purely a styling issue.

I use modals for forms all throughout my app and they work great for that purpose, they are a great solution for content that I need to pop up and hide when done. The only thing I am struggling with is autocomplete dropdowns. Though most of my site works well on mobile (including my modal forms), I have a different solution for mobile access to my app, so it is not my priority. Here is a pen to demonstrate what I am explaining in my original post:
https://codepen.io/rmountjoy/pen/xxxxrGx

They might work great for you but they might not work great for every user. You have been warned! ;)
I'm not 100% sure what you're trying to achieve but if you want the content of the dropdown to flow outside of the modal, you need to add this rule:
.modal {
  overflow: visible !important;
}

Forked amended Codepen:
https://codepen.io/doughballs/pen/QWWWgMZ

@rmountjoy92 did this fix the issue for you?

Added dropdownOptions to autocomplete component in cee8eac2


is there any existed work that apply this fantastic algorithm to BOP test?

Hi, first congratulate and respect to your great work!
I find the dataset structure in your "data preparation" part is different from that of the official BOP dataset, i.e. the official BOP dataset may not contain VOC2012 as background and the content in LM is different from yours. So I wonder how to test on BOP dataset (using BOP toolkit) with your EPro-pnp. Is there any suggestions or existed work? Thanks a lot!

Hi! We have not yet tested EPro-PnP using the BOP toolkit, since all the data interfaces are from the original CDPN implementation. The authors of CDPN did provide another codebase for BOP, though, which might be helpful.


Adding Drop and Rename APIs to Tables interface.

Pr for Issue-133

Being a table format, Iceberg has no concept of a database, thus no APIs for rename() and drop() for tables. That is, there is no hierarchy higher than a Table.
So what is the use case for these APIs? Is it for parity with HMS?

Being a table format, Iceberg has no concept of a database, thus no APIs for rename() and drop() for tables. That is, there is no hierarchy higher than a Table.
So what is the use case for these APIs? Is it for parity with HMS?

While writing Presto's iceberg connector and its test cases it felt like the Tables API is half baked in absence of drop , rename and possibly list. Take HiveTables implementation for example, because create needs to be implemented the HiveTables implementation  makes metastore calls and creates the table in HMS. But for other table level operations like rename and drop the client is expected to manage it outside of iceberg. This means any iceberg clients now needs to create wrappers on top of Tables implementation.
What is the downside of offering these APIs as part of iceberg?

I'm not sure if it is a good idea to add these or not. The Tables API was never properly thought through and I think it shows in how simple it is. It works for an easy entry point, but if we want to expose catalog operations, maybe we should add a real catalog API that can be used for a metastore interface. We've been building this in Spark.
Any support for that idea, instead of extending this interface when it wasn't very well designed?

+1 for the Catalog API.
This could help support implementing [some part of] HMS api and could help provide an Iceberg Catalog for Spark

+1 for Catalog API. I will write up a new PR and submit for review.

+1 to a purpose built Catalog API with a well defined use case.

Closing this PR


Automatic formatting on init can't be disabled

Hello!
https://github.com/ng-util/ng-util/blob/49dc0df07e2a39da237bd722601f376cf4964485/packages/monaco-editor/monaco-editor.component.ts#L68
But sometimes it's undesirable to format document automatically. Any way to disable that?

fixed by 13.1.0


@PathParams should always be URL encoded

Full discussion is at https://groups.google.com/forum/#!topic/restygwt/rb09rRqqFLs
I disagree with the "issue" reported in #184 and think that the fix for it, commit 2b07fa9, introduces additional problems.  I propose that the encoding changes in commit 2b07fa9 be reverted.

Created pull request #295

fixde via #295


utils.is_bf16_available does not check for MPS device

System Info
- `Accelerate` version: 0.29.2
- Platform: macOS-14.4.1-arm64-arm-64bit
- `accelerate` bash location: /opt/homebrew/Caskroom/miniconda/base/envs/ojk/bin/accelerate
- Python version: 3.10.13
- Numpy version: 1.24.1
- PyTorch version (GPU?): 2.2.1 (False)
- PyTorch XPU available: False
- PyTorch NPU available: False
- PyTorch MLU available: False
- System RAM: 32.00 GB
- `Accelerate` default config:
        - compute_environment: LOCAL_MACHINE
        - distributed_type: NO
        - mixed_precision: no
        - use_cpu: False
        - debug: False
        - num_processes: 1
        - machine_rank: 0
        - num_machines: 1
        - rdzv_backend: static
        - same_network: True
        - main_training_function: main
        - enable_cpu_affinity: False
        - downcast_bf16: no
        - tpu_use_cluster: False
        - tpu_use_sudo: False
        - tpu_env: []

Information

[ ] The official example scripts
[X] My own modified scripts

Tasks

[ ] One of the scripts in the examples/ folder of Accelerate or an officially supported no_trainer script in the examples folder of the transformers repo (such as run_no_trainer_glue.py)
[X] My own task or dataset (give details below)

Reproduction
Pretty straight forward.  Calling is_bf16_available returns True on MPS devices (e.g. Mac M1/M2)
from accelerate.utils import is_bf16_available

print(is_bf16_available())

>>> True

Expected behavior
It should return False.

cc @SunMarc

This should be fixed here !

I am closing this as it is being resolved!


aio: Fix compilation without worker threads

Signed-off-by: Vinicius Costa Gomes<EMAIL_ADDRESS>

Looks ok

I didn't test, but it seems right

lgtm

Pushed. Thanks.


Got War in Afghanistan (2001-Present), put 2021, it said it should have been 2014, checked the wiki page and it said 2001-2021

See title

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Please see https://github.com/tom-james-watson/wikitrivia/issues/12.
There's literally a message in the bug template explaining this too, by the way.

It was very unclear to me what “bad cards” means, if that’s what you’re referring to. Might want to make that clearer if by that you mean cards that pull data incorrectly, I read it as cards that shouldn’t be in the game because they are bad for gameplay.

On Jan 21, 2022, at 10:43 AM, Tom Watson @.***> wrote:

Please see #12.
There's literally a message in the bug template explaining this too, by the way.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.


Vertical Scrolling Support

Great library. Currently month change on horizontal scrolling. Do you have any plans to support vertical scrolling for month change?

I just release a new version.
Check the Example project.


User agent reports incorrect version

We should be bumping the version in the user agent with each release, and otherwise add a dev suffix when in-between releases.
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/c7052a545378e7e3cfaf62d5cbac6154c8efaa46/src/sqladmin-fetcher.ts#L41

Related this should be 0.2.0-dev.
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/c7052a545378e7e3cfaf62d5cbac6154c8efaa46/package.json#L3


expose the configuration file content for a controller

Allows the config flag to be optional (satisfying @derekwaynecarr ) and injects it into the start method (satisfying @enj).  I think both are possible using the unstructured scheme and type coersion
/assign @enj

@enj oh, and make sure it works before you merge it.

I will need to look into why openshift/service-serving-cert-signer#58 is broke next week...


chore: add unified publishing pipeline

@rzhao271 after moving the existing pipeline configuration to a different folder path, you will also need to adjust the pipeline settings on where to find it otherwise you will not get any runs. As you can see in this PR.


Added Shortcut Functionality

Also added File > Exit menu
User can now press the corresponding key on their keyboard (e.g. 0-9, [/,*,-,+,Enter], Escape)

Thanks for contributing.