Question: When attempting to set a wallpaper i recieve a segmentation fault. run with sudo the same.

wp::video::node is the base class for all the different types of nodes the scene can have. right now only the materials are implemented, so if your scene uses models, web-browser or video the content won't be displayed (in fact you should be seeing an error in the log).

As I haven't implemented the Wallpaper engine texture format yet only PNG/JPG textures are supported. #1
Right now this is as far as you can get with any background: URL
This is the background I'm loading in that picture: URL

You'll notice that for every material, there is a png or jpg file with the actual texture.

Shaders support is implemented but they aren't loaded yet from the project.json file as I still have to implement the parser for them.

When attempting to set a wallpaper i recieve a segmentation fault. run with sudo the same.
[luke@fedora build]$ ./wallengine /home/luke/.local/share/Steam/steamapps/workshop/content/431960/2677437153/
Detected scene.pkg file at /home/luke/.local/share/Steam/steamapps/workshop/content/431960/2677437153/scene.pkg. Adding to list of searchable paths
Found wallpaper engine's assets at /home/luke/.local/share/Steam/steamapps/common/wallpaper_engine/assets
Segmentation fault (core dumped)
[luke@fedora build]$

fixed location of program and retested still having the issue.

and sorry for weird build location i forgot to CD back before building when i tried to use a KDE plugin earlier.

I'll need some extra information. What DE are you using?
Could you please run it with GDB attached and give a backtrace of where the segfault is?

I am using gnome on x-11 as my DE, running on fedora. pardon me for asking but how do i run it with GDB and backtrace it?

You will need to run the software with gdb, just like you'd do with sudo:

gdb ./wallengine /home/luke/.local/share/Steam/steamapps/workshop/content/431960/2677437153/

That should give you a command prompt, if you write start and press enter the software will run as normal, once it hits the segfault you'll be back to the gdb's command prompt.
You can use the command "bt" to get some better information of what happened.

so far i have installed 2 sets of debug packages and it is asking me for more:
[luke@fedora build]$ gdb ./wallengine /home/luke/.local/share/Steam/steamapps/workshop/content/431960/2677437153/
GNU gdb (GDB) Fedora 11.2-2.fc35
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later < URL
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
< URL
Find the GDB manual and other documentation resources online at:
 < URL

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./wallengine...

This GDB supports auto-downloading debuginfo from the following URLs:
 URL
Enable debuginfod for this session? (y or [n])
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
(No debugging symbols found in ./wallengine)
"/home/luke/.local/share/Steam/steamapps/workshop/content/431960/2677437153/" is not a core dump: file format not recognized
(gdb) start
Temporary breakpoint 1 at 0x4c4276
Starting program: /home/luke/wallengine/build/wallengine
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libOpenCL.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/8b/1a5b9feb2f73098a0b3cc1fe1b7da5b32c1015.debug
Missing separate debuginfo for /lib64/libwbclient.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/7e/4d98ae1b739d161227923719ff0c12e2a4cf2b.debug

Temporary breakpoint 1, 0x00000000004c4276 in main ()
Missing separate debuginfos, use: dnf debuginfo-install LibRaw-0.20.2-3.fc35.x86_64 SDL2-2.0.20-1.fc35.x86_64 SDL_mixer-1.2.12-23.fc35.x86_64 bzip2-libs-1.0.8-9.fc35.x86_64 cairo-1.17.4-4.fc35.x86_64 cyrus-sasl-lib-2.1.27-14.fc35.x86_64 fftw-libs-double-3.3.8-11.fc35.x86_64 fontconfig-2.13.94-5.fc35.x86_64 freeglut-3.2.2-1.fc35.x86_64 freeimage-3.19.0-0.7.svn1889.fc35.x86_64 freetype-2.11.0-3.fc35.x86_64 fribidi-1.0.11-3.fc35.x86_64 gdk-pixbuf2-2.42.6-2.fc35.x86_64 glfw-3.3.4-3.fc35.x86_64 glib2-2.70.5-1.fc35.x86_64 glibc-2.34-30.fc35.x86_64 gmp-6.2.0-7.fc35.x86_64 gnutls-3.7.2-3.fc35.x86_64 gsm-1.0.19-6.fc35.x86_64 harfbuzz-2.9.1-1.fc35.x86_64 ilbc-1.1.1-21.fc35.x86_64 imath-3.1.5-1.fc35.x86_64 jasper-libs-2.0.33-1.fc35.x86_64 jbigkit-libs-2.1-22.fc35.x86_64 jxrlib-1.1-17.fc35.x86_64 keyutils-libs-1.6.1-3.fc35.x86_64 krb5-libs-1.19.2-6.fc35.x86_64 lame-libs-3.100-11.fc35.x86_64 lcms2-2.12-2.fc35.x86_64 libGLEW-2.1.0-10.fc35.x86_64 libICE-1.0.10-7.fc35.x86_64 libSM-1.2.3-9.fc35.x86_64 libX11-1.7.3.1-1.fc35.x86_64 libXext-1.3.4-7.fc35.x86_64 libXrandr-1.5.2-7.fc35.x86_64 libXrender-0.9.10-15.fc35.x86_64 libXxf86vm-1.1.4-17.fc35.x86_64 libaom-3.2.0-2.fc35.x86_64 libbluray-1.3.1-1.fc35.x86_64 libchromaprint-1.5.0-3.fc35.x86_64 libcom_err-1.46.3-1.fc35.x86_64 libdav1d-0.9.2-1.fc35.x86_64 libdrm-2.4.110-1.fc35.x86_64 libgcc-11.3.1-2.fc35.x86_64 libgcrypt-1.9.4-1.fc35.x86_64 libglvnd-1.3.4-2.fc35.x86_64 libglvnd-glx-1.3.4-2.fc35.x86_64 libgomp-11.3.1-2.fc35.x86_64 libgpg-error-1.43-1.fc35.x86_64 libicu-69.1-2.fc35.x86_64 libidn2-2.3.2-3.fc35.x86_64 libjpeg-turbo-2.1.0-3.fc35.x86_64 libldb-2.4.2-1.fc35.x86_64 libmodplug-0.8.9.0-13.fc35.x86_64 libmount-2.37.4-1.fc35.x86_64 libogg-1.3.5-2.fc35.x86_64 libopenmpt-0.5.15-1.fc35.x86_64 libpng-1.6.37-11.fc35.x86_64 librsvg2-2.52.8-1.fc35.x86_64 libsmbclient-4.15.6-0.fc35.x86_64 libssh-0.9.6-1.fc35.x86_64 libstdc++-11.3.1-2.fc35.x86_64 libtalloc-2.3.3-2.fc35.x86_64 libtdb-1.4.4-3.fc35.x86_64 libthai-0.1.28-7.fc35.x86_64 libtheora-1.1.1-30.fc35.x86_64 libudfread-1.1.2-2.fc35.x86_64 libunwind-1.5.0-1.fc35.x86_64 libuuid-2.37.4-1.fc35.x86_64 libva-2.13.0-3.fc35.x86_64 libvdpau-1.5-1.fc35.x86_64 libvmaf-2.1.1-3.fc35.x86_64 libvorbis-1.3.7-4.fc35.x86_64 libvpx-1.10.0-2.fc35.x86_64 libxcb-1.13.1-8.fc35.x86_64 libzstd-1.5.2-1.fc35.x86_64 lz4-libs-1.9.3-3.fc35.x86_64 mesa-libGLU-9.0.1-5.fc35.x86_64 mpg123-libs-1.26.5-2.fc35.x86_64 nettle-3.7.3-2.fc35.x86_64 openexr-libs-3.1.5-1.fc35.x86_64 openjpeg2-2.4.0-5.fc35.x86_64 openpgm-5.2.122-27.fc35.x86_64 openssl-libs-1.1.1n-1.fc35.x86_64 pango-1.50.4-1.fc35.x86_64 pixman-0.40.0-4.fc35.x86_64 rav1e-libs-0.5.0-1.fc35.x86_64 sdl12-compat-0.0.1~git.20211125.4e4527a-1.fc35.x86_64 speex-1.2.0-9.fc35.x86_64 srt-libs-1.4.4-1.fc35.x86_64 svt-av1-libs-0.8.7-2.fc35.x86_64 twolame-libs-0.3.13-18.fc35.x86_64 vapoursynth-libs-51-4.fc35.x86_64 xz-libs-5.2.5-9.fc35.x86_64 zlib-1.2.11-30.fc35.x86_64 zvbi-0.2.35-15.fc35.x86_64
(gdb)

ok after installing 3rd and 4th set of packages this is the output after start

(gdb) start
Temporary breakpoint 1 at 0x4c4276
Starting program: /home/luke/wallengine/build/wallengine
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Downloading separate debug info for /lib64/libOpenCL.so.1...
Missing separate debuginfo for /lib64/libOpenCL.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/8b/1a5b9feb2f73098a0b3cc1fe1b7da5b32c1015.debug

Temporary breakpoint 1, 0x00000000004c4276 in main ()
(gdb)

You need to run the "bt" command once you get back to the (gdb) prompt so it can show you where it actually crashed. It might be deep within opengl or something, but the crash has to originate from somewhere in my code.

Hello! I am facing the same issue as the other person is. Here's the output of GDB

(gdb) run /hdd0/SteamLibrary/steamapps/workshop/content/431960/2638696675/
Starting program: /home/kris/git/linux-wallpaperengine/build/wallengine /hdd0/SteamLibrary/steamapps/workshop/content/431960/2638696675/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Detected scene.pkg file at /hdd0/SteamLibrary/steamapps/workshop/content/431960/2638696675/scene.pkg. Adding to list of searchable paths
Found assets folder alongside the binary: /home/kris/git/linux-wallpaperengine/build/assets
[New Thread 0x7fffb827f640 (LWP 293361)]

Thread 1 "wallengine" received signal SIGSEGV, Segmentation fault.
0x000055555562d3b5 in WallpaperEngine::Audio::CAudioStream::loadCustomContent(char const*) ()
(gdb) bt
#0 0x000055555562d3b5 in WallpaperEngine::Audio::CAudioStream::loadCustomContent(char const*) ()
#1 0x000055555562d1fd in WallpaperEngine::Audio::CAudioStream::CAudioStream(void*, int) ()
#2 0x000055555565d7c3 in WallpaperEngine::Render::Objects::CSound::load() ()
#3 0x000055555565d673 in WallpaperEngine::Render::Objects::CSound::CSound(WallpaperEngine::Render::CScene*, WallpaperEngine::Core::Objects::CSound*) ()
#4 0x0000555555654693 in WallpaperEngine::Render::CScene::CScene(WallpaperEngine::Core::CScene*, WallpaperEngine::Assets::CContainer*, WallpaperEngine::Render::CContext*) ()
#5 0x000055555565322b in WallpaperEngine::Render::CWallpaper::fromWallpaper(WallpaperEngine::Core::CWallpaper*, WallpaperEngine::Assets::CContainer*, WallpaperEngine::Render::CContext*) ()
#6 0x000055555561c3b6 in main ()

I am at Tafe this week, so I will try running the BT command in GDB when I am back Friday night or Saturday

@t1stm your stack traces are interesting, both seem to happen on ffmpeg-related code (either audio or video) but I can load both backgrounds properly. What OS and version are you using? What ffmpeg version do you have installed?

@mihawk90 that's weird, you should at least be able to get the stacktrace up to the last call that happens in the wallpaper engine binary. I'm sorry but I'm no expert on GDB :/ Maybe you can try it in an IDE like VScode or CLion that have an interactive debugger?

@L-m-b no problem, ping me when you have it and i'll look into it ;)

@Almamu I use Arch Linux, and use Openbox as my window manager with the picom compositor. I am using the latest FFmpeg version on the AUR - ffmpeg-full, but the version from the official repo gives me the exact same error after removing the build directory and building again. The FFmpeg version is 5.0.1 from the AUR and 5.0.0 from the repo. FFmpeg works just fine encoding and decoding the videos. I tested the decoding using a pipe to MPV.

@Almamu I decided to start to look for problems, and found files in the /usr/local directory which came from an old FFmpeg build I compiled a year ago and removed some time after that. For some reason CMake was detecting these files and not the ones in the /usr directory, so if anyone here has compiled FFmpeg from source before, be sure to check your /usr/local directory for any old files. Anyways with that being fixed the wallpapers start normally, but my tint2 dock has an issue where the icons are flickering.

Me neither :/
This is as far as I get:

z% gdb wallengine ~/.local/share/Steam/steamapps/workshop/content/431960/2677437153
GNU gdb (GDB) Fedora 11.2-3.fc36
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later < URL
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
< URL
Find the GDB manual and other documentation resources online at:
 < URL

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from wallengine...
Reading symbols from /usr/lib/debug/usr/bin/wallengine-0.0.1.28f0868-1.fc36.x86_64.debug...
"/home/tarulia/.local/share/Steam/steamapps/workshop/content/431960/2677437153" is not a core dump: file format not recognized
(gdb) start
Temporary breakpoint 1 at 0x22620: file /usr/src/debug/linux-wallpaperengine-0.0.1.28f0868-1.fc36.x86_64/main.cpp, line 95.
Starting program: /usr/bin/wallengine

This GDB supports auto-downloading debuginfo from the following URLs:
 URL
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /home/tarulia/system-supplied DSO at 0x7ffff7fc4000...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Downloading separate debug info for /lib64/liblzma.so.5...
Downloading separate debug info for /lib64/libcrypto.so.3...
Downloading separate debug info for /home/tarulia/.cache/debuginfod_client/00404b8982ab681e4d574a5fa286c28f3844aeb6/debuginfo...
Downloading separate debug info for /lib64/libssl.so.3...

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdce8) at /usr/src/debug/linux-wallpaperengine-0.0.1.28f0868-1.fc36.x86_64/main.cpp:95
95 {
(gdb) bt
#0 main (argc=1, argv=0x7fffffffdce8) at /usr/src/debug/linux-wallpaperengine-0.0.1.28f0868-1.fc36.x86_64/main.cpp:95
(gdb)

I'm on F36 KDE spin.

Your backtrace is from a breakpoint placed on the start of the app, not from the actual crash. You should be able to continue execution until the app actually crashes (if I recall correctly the command is "continue").

That stacktrace isn't really that helpful... For some reason it's happening in one of the std::string methods, but there should be some calling code somewhere :/ Maybe
bt full
 will give some more precise information? @mihawk90

@mihawk90 that's a really useful stacktrace. I'll look into it today and fix it, seems a simple enough thing.

so starting off today i redownloaded the package, build the cmake side of things, then ran make.
[ 41%] Building CXX object CMakeFiles/wallengine.dir/src/WallpaperEngine/Render/CFBO.cpp.o
/home/luke/linux-wallpaperengine-main/src/WallpaperEngine/Render/CFBO.cpp: In member function ‘virtual const std::vector & WallpaperEngine::Render::CFBO::getFrames() const’:
/home/luke/linux-wallpaperengine-main/src/WallpaperEngine/Render/CFBO.cpp:98:17: warning: returning reference to temporary [-Wreturn-local-addr]
 98 | return std::vector ();
 | ^~~~~~~~~~~~~~~~~~~~~~~~
[ 43%] Building CXX object CMakeFiles/wallengine.dir/src/WallpaperEngine/Render/Objects/Effects/CPass.cpp.o
this warning came up during the setup.
but aside from that program installed and launched OK, but window was not on the background, but luckily kde allowed me to make it so.
you must have fixed it.

some of the scenes i have result in seg fault still, actually, old reactor is a good one to test that on

none of the shaders work, all wallpapers that do work end up still because of the lack of shaders, and the ones not entirely reliant on it don't launch, at least out of my library. the non scene backgrounds or scenes that only rely on html and etc, don't play at all.

Closing this one, please feel free to open one issue by background so I can delve a bit closer into what makes each one fail. Make sure to have the latest version downloaded.

wp::video::node::render() is empty?
The program gives me a solid black output, even after I modified the path to WallPaper Engine Projects folder, I see the `render()` method is empty, what does it (or at least should) do?

Okay, finally I tried the scene you provided and it works fine, but it's weird that I didn't receive any error message when I was using the *default scenes of Wallpaper Engine (like that car, and some DNA structure thing)*.

Thank you for the heads up, hopefully I'll be able to start testing with other wallpapers soon so I can fix more bugs and implement things like the the decompress routine for final backgrounds downloaded from the steam store.


Question: Update release GitHub workflows?

`maven-publish` itself supports cc since 7.6 and the `signing` plugin will in Gradle 8.1. However there is one big open blocker when publishing to maven central URL When configuration cache is enabled the repository url will be evaluated eagerly and not when the publishing tasks are executed. Since we are computing that url based on the output of the task that creates the staging repo the build will fail with this:

Configuration cache state could not be cached: field `repository` of `org.gradle.api.publish.maven.tasks.PublishToMavenRepository$PublishSpec` bean found in field `value` of `org.gradle.internal.Try$Success` bean found in field `result` of `org.gradle.internal.serialization.Cached$Fixed` bean found in field `spec` of task `:nexus:publishMavenPublicationToMavenCentralRepository` of type `org.gradle.api.publish.maven.tasks.PublishToMavenRepository`: error writing value of type 'org.gradle.api.publish.maven.tasks.PublishToMavenRepository$RepositorySpec$Configured'

 The value of this provider is derived from:
 - task ':nexus:createStagingRepository' property 'stagingRepositoryId'

So current status:
- Gradle 7.6: publishing to local or non maven central remote repositories works with cc when signing is disabled
- Gradle 8.1: publishing to local or non maven central remote repositories works with cc with signing enabled
- TBD: publishing to maven central works with cc

Update release GitHub workflows
I think the release workflows could be simplified.

* Use a single machine to publish everything - `macos-latest` can build all Kotlin targets.
* Just trigger `./gradlew publish` instead of listing all of the publish tasks separately.

In URL I introduced a BuildService with limited concurrency to try to avoid issues with Maven Central and parallel uploads. If it doesn't work, then the quickest and easiest fix is to add the flags `--no-configuration-cache org.gradle.parallel=false -Dorg.gradle.workers.max=1`.

We could also look into creating a staging repository before releasing - then Maven Central won't get confused about parallel uploads.

What are the problems with parallel uploads to Maven central? I've heard of it multiple times but don't know the details.

Should we also consider using URL I think it would automate the (otherwise) manual steps in Nexus as well?

When publishing, Maven Central creates a private, temporary, staging repository to collect the files. It does this automatically when it receives the first artifact. However, if there are multiple artifacts being published from multiple machines, it may create multiple staging repositories. The result is the files are split across multiple staging repos, so no staging repo is valid.

 URL

This can be avoided by not publishing in parallel, or manually creating the staging repo first (maybe there's an API to create a staging repo though?).

Possibly the new method of publishing to Maven Central is better? URL

It's not config-cache compatible :(

 URL

It looks like the release is broken because of parallel uploads.

 URL

[...]

BUILD FAILED in 4m 24s
281 actionable tasks: 251 executed, 30 from cache
Configuration cache entry discarded with 6 problems.
Error: Process completed with exit code 1.

[...]

With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!
Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

I'm working on updating the release config today.

If #4076 doesn't work, then we can try these GitHub actions to manually create/close staging repositories.

 URL

Configuration cache problems
Looks like there are some issues with using this plugin when the configuration cache is enabled. Not sure if any of this is internal to Gradle or part of the plugin, but figured I'd record it here.

Here's a build of mine that failed because of it.

I'll add support for it once the underlying Maven Publish and Signing plugins support configuration caching on the Gradle side URL

With Gradle 8.1 being out the updated status is
- Publishing releases to Maven Central (snapshots are fine), blocked by Gradle issue #22779.
- Kotlin Multiplatform projects, blocked by KT-49933.

Had to diable the configuration cache (`gradle-8.12`) as build was failing with the following error. Is this issue still blocked by URL ?

Configuration cache state could not be cached: field `repository` of `org.gradle.api.publish.maven.tasks.PublishToMavenRepository$PublishSpec` bean found in field `value` of `org.gradle.internal.Try$Success` bean found in field `result` of `org.gradle.internal.serialization.Cached$Fixed` bean found in field `spec` of task `:catalog:publishMavenPublicationToMavenCentralRepository` of type `org.gradle.api.publish.maven.tasks.PublishToMavenRepository`: error writing value of type 'org.gradle.api.publish.maven.tasks.PublishToMavenRepository$RepositorySpec$Configured'

Actually, just saw URL which seems like it might remove the issue altogether?

Yes with that PR we are compatible without any changes on Gradle's side needed.


Question: Step not saved (clash with precision?) (was: Add step editing (was: Slider min/max/step editing))?

Yup. There is a weird interplay between precision, round, and step. I think I've got it working...

Step not saved (clash with precision?) (was: Add step editing (was: Slider min/max/step editing))
This is step 2 from URL

Add the ability to edit the start/stop/round attributes of a slider (triple-click or shift-click, probably, popping up a dialog). This will be saved to a shared table, with options:

- just apply to this slider
- apply to all [cfg] sliders on [KSampler] nodes
- apply to all [cfg] sliders on any node

At this point the old mechanism will be retired (maybe auto converted, maybe not!)

Can you detect if a FLOAT or Primitive node is connected to a "cfg" input ?
And also apply the settings to these sliders.

If so, Step 3 ( the global slider table ) may not be necessary.

cfg

I think it's the lack of a slider editing system, that keeps sliders from being added to ComfyUI.

Because, apparently, you can already add a slider to a specific widget, if you change the code, and add the slider parameters:
 URL ( but your changes will be lost, the next time you update ComfyUI ).

If ComfyUI adds sliders, the Controller could use the same slider Settings.
But have no idea if/when they will add sliders ( or if they plan an editing system ).
At least they've moved my slider feature request to the litegraph issues ( URL )

@chrisgoringe In the documentation I suggest adding that the range you set on the controller slider will also be applied on the node widget.

I have the new edit GUI.
But the new step size is not applied to the slider.

The step size is not saved.
When open the edit GUI again, it shows the old step value.

stp

I found another issue. When you set a min/max range, it becomes difficult to change values on the widget using the arrows; many clicks to just change of 1 step

 URL

The new slider steps are being used in the slider.

But I still can't use the arrows in the node widgets, once the step is changed.

OK, I can see what's the issue.

I have the slider step size at 0.05, but the arrows change at 0.01 steps, so the resulting value is not allowed.

When I click down in the arrow it goes from 0.35 to 0.36
But on click up, it returns to 0.35

All the issues described above seem solved with the latest update.

Now I'm able to save step the slider settings. And they are kept when switching workflows.
And I can also use the widget arrows.

---

But I now have other issues: URL

I tried mostly with min (0), max (1) and step (0.05)

@JorgeR81 Have you tried saving step to 1 and then lowering to 0.1? Because I got the problem in the video

Yes, with Apply ControlNet I can use `min (0), max (1) and step (1)`, I had not issues

But with `min (0), max (1) and step (0.1)` the rounding is broken.

cn

@JorgeR81 Watch my video here URL I always had 1 decimal digit

Yeah

If you don't set the precision in the main comfy controls, cfg has a precision of 0.1, but a step size of 0.01, which makes no sense at all.

If you set step to 1, it gets confused into thinking the widget is an integer! I'll raise a new issue.

Not sure what's happened with the rounding.

Can't move slider with scroll if step less than precision (was: Setting to require shift-scroll for sliders)
By default the sliders respond to the scrollwheel.

This can be changed to make it so they require the shift key to be pressed.

I think there is a problem with the cfg, I can change all the other sliders except for cfg ones...

 URL

It's working for me.

Maybe that's a custom node ?

The `shift` key as another function on one of my custom nodes ( URL )

@JorgeR81 It can't be since the problem only occurs on CFG sliders.

This is a frontend function.

It doesn't work even in always mode, to it's not due to shift key

Could it be related to the default step size of 0.01?

step_size

(I tried scrolling as much as I can but it doesn't change a single value...)

I'll look at it. My guess is that there is a clash between step size and rounding (if it's rounded to 1 decimal place, but taking steps of 0.01).

After this fix, the other 2 issues I had are also fixed !

 URL
 URL

Ah, but now there is a different problem:

When dragging the slider, the new step interval is not used. It's only used with scroll.

Cfg now it's working, but they are all 2 decimal digits instead of 1

This with the latest update:

- When dragging the slider, the new step interval ( 0.05 ) is not used. - **NOT FIXED**

- The widget arrows, in the node, don't use the new step interval. - FIXED

Everything seems to work:
- I can apply the new step size to multiple nodes.
- The new step size is applied, when scrolling and dragging sliders or using the widget arrows.
- The new min / max are applied to the widgets


Question: Syntax issue using PREFERRED PARAMETER?

if you change the code to use functional writing, I think it should work, as a workaround.... URL

Syntax issue using PREFERRED PARAMETER
Hello,

I have syntax errors in my abaplint result set, that a importing parameter IV_STRING is not given into the method.
Syntax_error_prefered_parameter_1

The importing parameter IV_STRING is definied as prefered parameter.
Syntax_error_prefered_parameter_3

According to SAP help this option "prefered parameter" says, that parameter is implicitly set to optional.
Syntax_error_prefered_parameter_2

Therefore abaplint should not return an error in that case. SAP himself is not raising issues.

Thanks.

Best regards,
Dominik

You can reproduce by adding this code to playground.

REPORT zfoobar.

CLASS lcl_tele_mapping DEFINITION.

 PUBLIC SECTION.

 CLASS-METHODS replaceit
 IMPORTING
 !iv_new_char TYPE char1 OPTIONAL
 !iv_old_char TYPE char1 DEFAULT '.'
 !iv_string TYPE char100
 PREFERRED PARAMETER iv_string
 RETURNING
 VALUE(rv_string) TYPE char100.

 PROTECTED SECTION.
 PRIVATE SECTION.
ENDCLASS.

CLASS lcl_tele_mapping IMPLEMENTATION.

 METHOD replaceit.
 IF iv_new_char = iv_old_char.
 RETURN.
 ENDIF.
 ENDMETHOD.

ENDCLASS.

FIELD-SYMBOLS TYPE char100.
 = lcl_tele_mapping=>replaceit( iv_new_char = 'A'
 iv_old_char = 'B' ).

Thanks for the hint :-) Now example code looks good I suppose ;-)

add "abap" after the first 3 pings then it will also syntax highlight

abap
WRITE highlighted.

shorter reproduced as

abap
CLASS lcl_tele_mapping DEFINITION.
 PUBLIC SECTION.
 CLASS-METHODS replaceit
 IMPORTING
 iv_new TYPE i OPTIONAL
 iv_string TYPE string
 PREFERRED PARAMETER iv_string.
ENDCLASS.

CLASS lcl_tele_mapping IMPLEMENTATION.
 METHOD replaceit.
 ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
 lcl_tele_mapping=>replaceit( iv_new = 2 ).
 lcl_tele_mapping=>replaceit( 'A' ).

Working well now - thank you!
I have checked syntax now for our namespace with about 20.000 objects and only have 4 issues left (all same type of issue - see ticket #2826). That's really great!

Syntax issue - Method importing parameter "IV_..." does not exist (check_syntax) [E]
Hello,

I have a syntax issue which is not explainable and shouldn't be an issue in real.
Syntax_error_import_parameter_1

Problem is, that IV_DOCID seems to be not existing.
Syntax_error_import_parameter_2

The attribute MO_SRV_DLV_INB himself is from type class /MYCOMP/CL_SRV_DLV_INB. This class himself does not include the method BO_UPDATE_BATCH because this method will be inherited from the super class which is /MYCOMP/CL_SRV_DLV_BASE. But also there the interface /MYCOMP/IF_SRV_DLV is used which includes the method interface.
Syntax_error_import_parameter_3
Syntax_error_import_parameter_4

So for me everything looks fine and also within SAP system there is no syntax issue. I have a couple of such issues in the syntax check via abaplint (via gitlab). This is my JSON config file.

abaplint_syntax_json

Thanks for checking.

Best regards,
Dominik

I reproduced this issue with the playground. Just add the namespace /MYCOMP/ to the error namespace and paste coding below.
image

For me it seems, that abaplint will try to run BO_UPDATE_BATCH of class /MYCOMP/CL_SRV_BATCH in line 99 instead of calling method BO_UPDATE_BATCH of attribut MO_SRV_DLV_INBOUND (which is class /MYCOMP/CL_SRV_DLV_INB). So the expected result is, that BO_UPDATE_BATCH is not found because class /MYCOMP/CL_SRV_DLV_INB is unknown (not part of the playground).

To test my theory, try to comment line 101, 102 and 104 and then result set says, that IV_PRODUCTNO is expected and thats for me the indicator that abaplint is trying to run BO_UPDATE_BATCH of class /MYCOMP/CL_SRV_BATCH.

image

Thanks a lot!

BR
Dominik

_REPORT zfoobar.

interface /MYCOMP/IF_SRV_BATCH
 public.

 methods BO_UPDATE_BATCH
 importing
 !IV_PRODUCTNO type /SCWM/DE_MATNR
 !IV_BATCHNO type /SCWM/DE_CHARG
 !IV_SLED type /SCWM/SLED optional
 !IV_REREAD_BATCH type XFELD default ABAP_FALSE
 !IV_RETRIES type I default '10'
 !IV_COMMIT type XFELD default ABAP_FALSE
 !IV_WAIT type XFELD default ABAP_FALSE
 !IV_ENTITLED type /SCWM/DE_ENTITLED optional
 !IT_VAL_NUM type TT_BAPI1003_ALLOC_VALUES_NUM optional
 !IT_VAL_CHAR type TT_BAPI1003_ALLOC_VALUES_CHAR optional
 !IT_VAL_CURR type TT_BAPI1003_ALLOC_VALUES_CURR optional
 exporting
 !EV_BATCHNO type /SCWM/DE_CHARG
 !EO_BATCH type ref to /SCWM/CL_BATCH_APPL
 !EV_NOT_EXISTS type XFELD
 raising
 /MYCOMP/CX_SRV_ROOT .

 methods BO_UPDATE_BATCH_ON_HU_ITEM
 importing
 !IV_BATCHID type /SCWM/DE_BATCHID optional
 !IV_BATCHNO type /SCWM/DE_CHARG optional
 !IV_PROCTY type /SCWM/DE_PROCTY
 !IV_REASON type /SCWM/DE_REASON optional
 !IV_GUID_PARENT_HU type /LIME/GUID_PARENT
 !IV_GUID_STOCK type /LIME/GUID_STOCK
 !IV_COMMIT type XFELD default ABAP_FALSE
 !IV_WAIT type XFELD default ABAP_FALSE
 exporting
 !ET_LTAP_VB type /SCWM/TT_LTAP_VB
 !ET_BAPIRET type BAPIRETTAB
 raising
 /MYCOMP/CX_SRV_ROOT .

 methods BO_UPDATE_BATCH_ON_DLV_ITEM
 importing
 !IV_DOCCAT type /SCDL/DL_DOCCAT
 !IV_DOCID type /SCDL/DL_DOCID
 !IV_ITEMID type /SCDL/DL_ITEMID
 !IV_BATCHNO type /SCWM/DE_CHARG
 !IV_COMMIT_WORK type XFELD default ABAP_FALSE
 !IV_WAIT type XFELD default ABAP_FALSE
 raising
 /MYCOMP/CX_SRV_ROOT .

endinterface.

class /MYCOMP/CL_SRV_BATCH definition
 public
 create protected

 global friends /MYCOMP/CL_SRV_FACTORY .

public section.

 interfaces /MYCOMP/IF_SRV_BATCH .

 aliases BO_UPDATE_BATCH
 for /MYCOMP/IF_SRV_BATCH~BO_UPDATE_BATCH .
 aliases BO_UPDATE_BATCH_ON_DLV_ITEM
 for /MYCOMP/IF_SRV_BATCH~BO_UPDATE_BATCH_ON_DLV_ITEM .
 aliases BO_UPDATE_BATCH_ON_HU_ITEM
 for /MYCOMP/IF_SRV_BATCH~BO_UPDATE_BATCH_ON_HU_ITEM .

 methods CONSTRUCTOR
 importing
 !IO_LOG type ref to /MYCOMP/CL_LOG optional
 !IV_LGNUM type /SCWM/LGNUM
 !IV_NO_LOG type XFELD default ABAP_FALSE
 raising
 /MYCOMP/CX_SRV_INPUT_INITIAL .

 PROTECTED SECTION.

 data MO_SRV_DLV_INB type ref to /MYCOMP/CL_SRV_DLV_INB .
 data MO_SRV_HU type ref to /MYCOMP/CL_SRV_HU .

 PRIVATE SECTION.

ENDCLASS.

CLASS /MYCOMP/CL_SRV_BATCH IMPLEMENTATION.

 METHOD constructor.
 ENDMETHOD.

 METHOD bo_update_batch.
 ENDMETHOD.

 METHOD bo_update_batch_on_dlv_item.

 CALL METHOD me->mo_srv_dlv_inb->bo_update_batch
 EXPORTING
 iv_docid = iv_docid
 iv_itemid = iv_itemid
 iv_batchno = iv_batchno
 iv_commit_work = iv_commit_work
 iv_wait = iv_wait.

 ENDMETHOD.

 METHOD bo_update_batch_on_hu_item.

 CALL METHOD me->mo_srv_hu->bo_update_batch_on_hu_item(
 EXPORTING
 iv_batchid = iv_batchid
 iv_batchno = iv_batchno
 iv_procty = iv_procty
 iv_reason = iv_reason
 iv_guid_parent_hu = iv_guid_parent_hu
 iv_guid_stock = iv_guid_stock
 iv_commit = iv_commit
 iv_wait = iv_wait
 IMPORTING
 et_ltap_vb = et_ltap_vb
 et_bapiret = et_bapiret ).

 ENDMETHOD.

ENDCLASS._

so, something like the below reproduces the same issue?

abap
INTERFACE if_srv.
 METHODS update_batch.
 METHODS update_line.
ENDINTERFACE.

CLASS cl_srv_batch DEFINITION.
 PUBLIC SECTION.
 INTERFACES if_srv.
 ALIASES update_batch FOR if_srv~update_batch.
 ALIASES update_line FOR if_srv~update_line.

 PROTECTED SECTION.
 DATA foobar TYPE REF TO voided.
ENDCLASS.

CLASS cl_srv_batch IMPLEMENTATION.
 METHOD update_batch.
 ENDMETHOD.

 METHOD update_line.
 CALL METHOD me->foobar->update_batch
 EXPORTING
 iv_docid = 2.
 ENDMETHOD.
ENDCLASS.

image

I doublecheck your example and yes same principle issue. Object _foobar_ is referenced to another class and abaplint seems to identify the method call (signature) in line 23 as the method which is in the interface _if_srv_, but that's not true. Because w/o assigning _iv_docid_ no syntax issue. On the other hand you can typ _foobar_ ref to any kind of z-class e.g. and there is no error shown, that class is unknown. This is the expected behavior, also in your example above.

You are right - It's working with the functional writing. Thank you 👍 Is it planned to provide a long term fix?

long term fix: yes, just takes time, and I need to concentrate for rewriting stuff 😅

Hello,
I have rechecked with old calling variant and with the newest abaplint version (2.9.53) and finally the issue is fixed. So thanks a lot for providing also a bugfix for that :-) It was a very short term long term fix ;-)
Best regards,
Dominik

yea, well, sometimes its difficult to get stuff working, ABAP is a messed up language


Question: App not opening on Windows 11?

So assuming that's fixed, I believe the original issue this thread is based on is a problem with the 2022 version that is not present in the main branch. Here's a pre-release build of the main branch for anyone else finding this issue later:
pathplanner-windows.zip

I'll close this after the 2023 version is released.

App not opening on Windows 11
I downloaded the app from both the Microsoft store, as well as the manual .zip installation. It is not opening from either place. My cursor shows the blue circle loading icon for about half a second and then nothing happens. I am not able to replicate this issue on any Windows 10 machines.

Did you download the 2023 beta version? This sounds like a duplicate of #117 which is fixed.

I am using 2023.0.1 pathplanner lib, but only 2023.0.0 is working. 2023.0.1 doesn't work still

Pathplanner doesn't launch on my computer
Pathplanner will no longer launch on my Windows 11 computer. It definitely hasn't worked since updating to the newest Windows version (22H2), but I honestly don't know if the update caused it to not work. I know it was working some time (like a month) before updating, and it isn't working now (like a week after updating). I've tried uninstalling and re-installing from the windows store, as well as downloading the exe directly and running it, but the app didn't launch in either of those cases.

This is really hard to diagnose so can you install flutter and run the app in debug mode? If it still crashes this should give you some error output.

We (3467) are also experiencing the same issue, Windows 11 22H2. Can you post more specific instructions on how to grab the debug info you need?

Follow these instructions: URL

Make sure you use `flutter run` to run in debug mode. I'm assuming this is an issue with the 22H2 update messing up some dependency needed to run. Building manually could potentially install these dependencies and work fine. If that doesn't work you could try installing Visual Studio Community (make sure the "Desktop Development with C++" module is installed with it) which might fix it as well. If all that fails then I don't think there's much I can do besides wait for a flutter update to fix the issue.

Some initial searching led me to this issue: URL

Working on building from source now.

It looks like Bitsdojo Window library was removed in May, but there hasn't been a release since March. Is it possible to send a newer Windows binary over? The Flutter setup is taking quite a while.

After running the latest version with `flutter run` this confirmed my suspicions. The issue was likely bitsdojo_window. I'll build a new version for Windows and post it here for anyone still having this problem.

Yeah that sounds right. Here's the one i built that includes some redistributables that some people might not have so its better to use this one. Keep in mind this version might have unknown issues and pathplanner lib doesn't support all of the functionality if you're using the release version.

PathPlanner-windows.zip

Beat me to it! We'll use this one for now. Thanks for your help.

I have the same problem, here is what I got after running in debug mode.

Launching lib\main.dart on Windows in debug mode...
Building Windows application...
[ERROR:flutter/shell/platform/windows/direct_manipulation.cc(137)] CoCreateInstance(CLSID_DirectManipulationManager, nullptr, CLSCTX_INPROC_SERVER, IID_IDirectManipulationManager, &manager_) failed
Syncing files to device Windows... 518ms

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h List all available interactive commands.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).

💪 Running with sound null safety 💪

An Observatory debugger and profiler on Windows is available at: URL
flutter: ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
flutter: │ RangeError (index): Invalid value: Valid value range is empty: 0
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ #0 List.[] (dart:core-patch/growable_array.dart:264:36)
flutter: │ #1 Trajectory.calculateVelocity (package:pathplanner/services/generator/trajectory.dart:187:13)
flutter: │ #2 Trajectory.generateSingleTrajectory (package:pathplanner/services/generator/trajectory.dart:87:5)
flutter: │ #3 Trajectory.generateFullTrajectory (package:pathplanner/services/generator/trajectory.dart:67:30)
flutter: │ #4 RobotPath.generateTrajectory. (package:pathplanner/robot_path/robot_path.dart:79:46)
flutter: │ #5 new Future. (dart:async/future.dart:253:37)
flutter: │ #6 _rootRun (dart:async/zone.dart:1383:47)
flutter: │ #7 _CustomZone.run (dart:async/zone.dart:1293:19)
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ 08:10:16.131 (+0:00:01.484156)
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ ⛔ Dart Error
flutter: └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Lost connection to device.

Just tried to run the same application since yesterday and can't get it to start nor the version I built, but running with `flutter run` in debug mode starts fine.

Can `flutter run` build the app without an Internet connection?

@Gameknight77YT it looks like one of your path files is messed up for some reason. Try removing them from your robot project and see if it will launch then.

@ehamwey No idea why it would work in debug mode but not release mode. Only thing I could think of would be to run in debug mode and just don’t close it. I guess worst case you can just connect to a hotspot or Wi-Fi to run it again. Unfortunately flutter checks for dependencies every time you run so you need to be online. There should be a log file in C:/Users/{YOUR USER}/AppData/Roaming/pathplanner something (don’t remember the exact folder) check that after trying to open the built app and maybe it will have something.

I did that and it is working now. I then readded them one at a time. The problem was one of them had an endpoint that was also a stop point.

That probably happened when you deleted another point in the path. I'll make a separate issue to fix that.

@ehamwey when you get a chance can you pull changes for the repo and see if builds you make will run now? I fixed a crash that *may* have been what caused your builds to crash but I'm not sure. If not then I'm really not sure what's going on there unless you can find some error output.

We had to `flutter pub upgrade` to get the builds working, but once it was built we have an offline version that works. Thanks for your help again. I think I may have moved the Release folder out of the build directory originally which messed with the binary paths.

Looks like after a reboot the built binary does not run. Any thoughts?

Is there anything in `%AppData%/com.mjansen4857/pathplanner/log.txt`?

Negative - it's empty.
We were getting an error relating to how the built directories were moved, which seemed to have fixed itself once we connected to WiFi? So I'm trying a clean and build in the final destination directory to see if that resolves things, then we're rebooting and testing offline.

Moving the built app shouldn't do anything. Just to confirm, after building you're running the exe in `pathplanner/build/windows/runner/Release` right?

Yep - moving the entire `pathplanner` folder.

Seems like it will run on WiFi, but not with WiFi off.

By WiFi on/off do you mean connected/disconnected from a network or actually turning the WiFi off in the settings?

Never mind, I can reproduce it. This is something, thanks. I'll look into it.

I'm going to try on Flutter 3.3.4, we're currently running 3.5.0 because of the method we installed it by. I don't think that should fix the problem but will try anyway.

Found the issue and fixed it. Was a quirk of how dart try/catch blocks work so checking for PathPlannerLib updates would crash. Pull changes and try again.

I'd definitely use 3.3.4 as well since 3.5 is a beta and I'm currently using 3.3.4.


Question: Access to AWS to test gdalcubes in large collections?

This might be caused by the GDAL error handler defined by the `sf` package. The GDAL error handler (set with
`CPLSetErrorHandler`) might be called from threads created by gdalcubes but the error handler calls `Rf_warning()` (see URL which is not thread-safe. However, a single-thread test, where all computations run in the main thread should clarify further.

Access to AWS to test gdalcubes in large collections
Dear Marius:

Do you have access to AWS to test gdalcubes? We had problems when regularizing large image collections. The problems are not simple to reproduce, because they occur when trying to run `gdalcubes` on big data.

Dear Gilberto, I've fixed two major issues that might be related:

1. The stack overflow crash (see #48)
2. If images on Amazon S3 are not available but STAC points to them (resulting in 404 errors in GDALOpen), these are now simply ignored. Previously, the errors stopped the computation of the current chunk and hence may have caused _corrupt_ chunks.

That being said, I do have access to AWS and successfully computed a Sentinel-2 composite over Germany at 10m resolution using approx. 500 Sentinel-2 images.

I am still doing some more tests but plan to do a CRAN release next week or so. If you have any examples with sits, I'd be happy to try it out with the new gdalcubes version.

@gilbertocamara New CRAN version just released (binary package builds may take some more days).

Stack overflow: Error : C stack usage * is too close to the limit
Occasionally, creating a data cube crashes with a stack overflow and/or a corrupt result file. Unfortunately, this happens mostly after performing several operations but there is no reproducible example yet. Some tests to find out the source include the following:

1. The behavior was never observed outside of R (i.e. when using the simple gdalcubes command line client to create cubes).
2. Disabling the progress bar does not solve the issue
3. Using RcppThread for creating C++ threads does not solve the issue

It seems that increasing the maximum stack size with `ulimit -s` can _solve_ the issue

Commit e79f4ed seems to fix the issue by calling `CPLPushErrorHandler()` before threads are started (or as a first call within a thread). Hoever, the issue will remain open until changes are merged into master.

Time for a new CRAN release? @rhijmans this might also be of interest to terra development.

v0.6.0 is now on CRAN (binary package builds may take some more days)


Question: Consider pushing out a new release?

Similar report just came in #435, too.

I believe something changed in the alpine image, since we test alpine in the CI pipeline and it passed last week, but started failing yesterday with the new image

- pass URL
- fail URL

Will investigate. In the meantime, a workaround is to use `ruby:3-alpine3.18`

Consider pushing out a new release
### Steps to reproduce

rails new demo
cd demo
DOCKER_BUILDKIT=1 docker build .

### Expected behavior

Build succeeds.

### Actual behavior

Fails with Ruby 3.4.2 (obtained via brew)

10.42 Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
10.42
10.42 current directory: /usr/local/bundle/ruby/3.4.0/gems/psych-5.2.3/ext/psych
10.42 /usr/local/bin/ruby extconf.rb
10.42 checking for pkg-config for yaml-0.1... not found
10.42 checking for yaml.h... no
10.42 yaml.h not found
10.42 *** extconf.rb failed ***

### System configuration

**Rails version**: `Rails 8.0.1`

**Ruby version**: `ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]`

### See also

 URL

I had to add `libyaml-dev` to the `Dockerfile`, so that the install line change from:

RUN apt-get update -qq && \
 apt-get install --no-install-recommends -y build-essential git libpq-dev pkg-config && \
 rm -rf /var/lib/apt/lists /var/cache/apt/archives

to:

RUN apt-get update -qq && \
 apt-get install --no-install-recommends -y build-essential git libyaml-dev libpq-dev pkg-config && \
 rm -rf /var/lib/apt/lists /var/cache/apt/archives

@pas256 indeed. That fix was already merged (on January 14th!) in URL ; all we need now is a release.

URL can produce a Dockerfile for your Rails application as it exists now, as opposed to when it was first created. It works for all current releases of Rails and Ruby, and has options to produce an Alpine dockerfile.

Rails = 3.18.

"symbol not found" on alpine 3.19
**TL;DR from the maintainers -- read me first!**

You can work around this issue in two ways:

1. pin to alpine 3.18
2. compile the gem from source, see INSTALLATION.md

Pick one! Permanent fix is being worked on upstream in rake-compiler-dock URL

Thanks for your patience :heart:

(The original bug description follows)

-----

On the latest ruby image with alpine 3.19, I can install `sqlite3` ruby gem, but it emits "symbol not found" errors at runtime.

This is a quick test on alpine 3.18:

$ docker run --rm -it ruby:3.2.2-alpine3.18 /bin/sh
/ # gem install sqlite3
Fetching sqlite3-1.6.9-x86_64-linux.gem
Successfully installed sqlite3-1.6.9-x86_64-linux
1 gem installed

A new release of RubyGems is available: 3.4.10 → 3.4.22!
Run `gem update --system 3.4.22` to update your installation.

/ # ruby -rsqlite3 -e 'puts SQLite3::SQLITE_LOADED_VERSION'
4.44.2
/ #

And here's the same on 3.19:

$ docker run --rm -it ruby:3.2.2-alpine3.19 /bin/sh
/ # gem install sqlite3
Fetching sqlite3-1.6.9-x86_64-linux.gem
Successfully installed sqlite3-1.6.9-x86_64-linux
1 gem installed

A new release of RubyGems is available: 3.4.10 → 3.4.22!
Run `gem update --system 3.4.22` to update your installation.

/ # ruby -rsqlite3 -e 'puts SQLite3::SQLITE_LOADED_VERSION'
 :85:in `require': cannot load such file -- sqlite3/sqlite3_native (LoadError)
 from :85:in `require'
 from /usr/local/bundle/gems/sqlite3-1.6.9-x86_64-linux/lib/sqlite3.rb:6:in `rescue in '
 from /usr/local/bundle/gems/sqlite3-1.6.9-x86_64-linux/lib/sqlite3.rb:2:in ` '
 from :159:in `require'
 from :159:in `rescue in require'
 from :39:in `require'
 :85:in `require': Error relocating /usr/local/bundle/gems/sqlite3-1.6.9-x86_64-linux/lib/sqlite3/3.2/sqlite3_native.so: posix_fallocate64: symbol not found - /usr/local/bundle/gems/sqlite3-1.6.9-x86_64-linux/lib/sqlite3/3.2/sqlite3_native.so (LoadError)
 from :85:in `require'
 from /usr/local/bundle/gems/sqlite3-1.6.9-x86_64-linux/lib/sqlite3.rb:4:in ` '
 from :159:in `require'
 from :159:in `rescue in require'
 from :39:in `require'
 :85:in `require': cannot load such file -- sqlite3 (LoadError)
 from :85:in `require'
/ #

I'm not sure if this is the gem or the docker image causing the issue here.

I copied `/lib/ld-musl-x86_64.so.1` from `ruby:3-alpine3.18` Docker image and that seems to fix the problem, so it would appear that the problem is related to some change in Musl libc or how Musl is compiled.

By looking the exported symbols from the library (e.g., `readelf -Ws --dyn-syms /lib/ld-musl-x86_64.so.1 | grep posix_fallocate64`) I've confirmed that the symbol `posix_fallocate64` is present in the previous version but missing in the new version. I'm not sure yet if this was intended or if it was an oversight. I'll try to dig more.

Just a note: the symbol missing for the user in #435 is `fcntl64`, where the one reported missing in this issue is `posix_fallocate64`.

OK, it seems this was an intentional breaking change in Musl 1.24:

So if I understood correctly, functions with the `64` suffix were dropped and the correct fix is to use the unsuffixed versions instead.

Here are examples of other projects that were also affected by this:
- URL
- URL

@pdfrod Thank you so much for doing this research! I should have time tomorrow to investigate if I can work around this in the native (precompiled) gems.

I'm not sure there's a fix for this other than for rake-compiler-dock to support generating native musl-specific gems. Upstream issue is URL

Thanks for looking into this; I did wonder if it was upstream.

I'll pin to alpine-3.18 for now.

I've updated the issue description with a TLDR summary of the workarounds.

Confirm a breaking change in the Alpine image. I redeployed the same app with no change to the `Gemfile` or `Dockerfile` and now receive this error:

[info] /usr/local/bundle/gems/sqlite3-1.7.0-x86_64-linux/lib/sqlite3.rb:6:in `require': cannot load such file -- sqlite3/sqlite3_native (LoadError)
[info] Did you mean? sqlite3/3.3/sqlite3_native
[info] sqlite3/3.2/sqlite3_native
[info] sqlite3/3.1/sqlite3_native
[info] sqlite3/3.0/sqlite3_native
[info] from /usr/local/bundle/gems/sqlite3-1.7.0-x86_64-linux/lib/sqlite3.rb:6:in `rescue in '
...

And that this diff got my deploy working again:

diff
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,4 +1,4 @@
-FROM ruby:3.2.2-alpine AS base
+FROM ruby:3.2.2-alpine3.18 AS base

( :wave: :wave: Hi Mike)


Question: 'quarto publish gh-pages' does not respect output-dir?

@tg-x Please open a new thread ( URL with sufficient details for your request after double checking it's not something already possible, if there are alternatives. Thank you!
Note that `quarto publish` is not intended to cover all possible use cases, *i.e.*, you can can use `quarto render` and then take control of the publishing part to do whatever you need to do.
GitHub Pages does not care about branches other than `gh-pages`, so adding a parameter to publish to GitHub Pages on another branch does not make sense.

'quarto publish gh-pages' does not respect output-dir
### Bug description

Quarto docs specify to set `output-dir: docs` for gh-pages: URL -- and set `docs/` as the target directory in the Github Pages config.

However, running `quarto publish gh-pages` appears to ignore the `output-dir` setting.
- input: URL
- `gh-pages` after running `quarto publish gh-pages` locally (successfully): URL

This means I need to set the Github Pages config to use ` ` instead of `docs/`.

Running `quarto render` locally puts the output in `docs/` as expected.

---

- macOS 12.4

- quarto version:

base ❯ quarto check

[✓] Checking Quarto installation......OK
 Version: 0.9.629
 Path: /Applications/quarto/bin

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
 Version: 3.9.13 (Conda)
 Path: /Users/inorton/opt/conda/bin/python
 Jupyter: (None)

 Jupyter is not available in this Python installation.
 Install with conda install jupyter

[✓] Checking R installation...........OK
 Version: 4.1.0
 Path: /Library/Frameworks/R.framework/Resources
 LibPaths:
 - /Users/inorton/Library/R/x86_64/4.1/library
 - /Library/Frameworks/R.framework/Versions/4.1/Resources/library
 rmarkdown: 2.9

[✓] Checking Knitr engine render......OK

### Checklist

- [X] formatted your issue so it is easier for us to read?
- [X] included a minimal, self-contained, and reproducible example?
- [X] documented the quarto version you're running, by providing the output produced by `quarto check` in a terminal in your issue?
- [ ] documented the RStudio IDE version you're running (if applicable), by providing the value displayed in the "About RStudio" main menu dialog?
- [X] documented which operating system you're running? If on Linux, please provide the specific distribution as well.
- [ ] upgraded to the latest version, including your versions of R, the RStudio IDE, and relevant R packages?

The docs on the website need to be updated. `quarto publish gh-pages` is specifically made to work with the `gh-pages` branch not a docs directory. We will do this soon.

It would be useful to be able to specify an output path inside the gh-pages branch,
to support publishing different branches to different paths from github actions

@tg-x Please don't post multiple times the exact same message. It does not help.
See < URL

Both issues are/were about output directory. You are talking about branches.

`quarto publish gh-pages`does not respect `output-dir: _site`
### Bug description

Related to #1246, `quarto publish gh-pages`does not respect `output-dir: _site`
instead renders to `./`.

`_quarto.yml` full [here]

yml
project:
 type: website
 output-dir: _site

The last `quarto publish` call results can be seen here

~/G/eyayaw.github.io (main)> quarto publish gh-pages

`
? Update site at URL (Y/n) › Yes
From URL
 * branch gh-pages -> FETCH_HEAD
Rendering for publish:

[1/6] bio.qmd
[2/6] posts/2022-07-31_welcome/index.qmd
[3/6] posts/2022-08-01_ten-baser-tips/index.qmd
[4/6] blog.qmd
[5/6] research.qmd
[6/6] index.qmd

Preparing worktree (resetting branch 'gh-pages'; was at b76bb45)
Branch 'gh-pages' set up to track remote branch 'gh-pages' from 'origin'.
HEAD is now at b76bb45 publish gh-pages
[gh-pages 087d8da] Built site for gh-pages
 32 files changed, 6880 insertions(+), 41 deletions(-)
 create mode 100644 bio.html
 create mode 100644 blog.html
 create mode 100644 index.html
 create mode 100644 posts/2022-07-31_welcome/index.html
 create mode 100644 posts/2022-08-01_ten-baser-tips/index.html
 create mode 100644 research.html
 create mode 100644 site_libs/bootstrap/bootstrap-dark.min.css
 create mode 100644 site_libs/bootstrap/bootstrap-icons.css
 create mode 100644 site_libs/bootstrap/bootstrap-icons.woff
 create mode 100644 site_libs/bootstrap/bootstrap.min.css
 create mode 100644 site_libs/bootstrap/bootstrap.min.js
 create mode 100644 site_libs/clipboard/clipboard.min.js
 create mode 100644 site_libs/quarto-html/anchor.min.js
 create mode 100644 site_libs/quarto-html/popper.min.js
 create mode 100644 site_libs/quarto-html/quarto-syntax-highlighting-dark.css
 create mode 100644 site_libs/quarto-html/quarto-syntax-highlighting.css
 create mode 100644 site_libs/quarto-html/quarto.js
 create mode 100644 site_libs/quarto-html/tippy.css
 create mode 100644 site_libs/quarto-html/tippy.umd.min.js
 create mode 100644 site_libs/quarto-html/zenscroll-min.js
 create mode 100644 site_libs/quarto-listing/list.min.js
 create mode 100644 site_libs/quarto-listing/quarto-listing.js
 create mode 100644 site_libs/quarto-nav/headroom.min.js
 create mode 100644 site_libs/quarto-nav/quarto-nav.js
 create mode 100644 site_libs/quarto-search/autocomplete.umd.js
 create mode 100644 site_libs/quarto-search/fuse.min.js
 create mode 100644 site_libs/quarto-search/quarto-search.js
 rewrite sitemap.xml (75%)
origin URL (fetch)
origin URL (push)
remote: This repository moved. Please use the new location:
remote: URL
To URL
 b76bb45..087d8da HEAD -> gh-pages

[✓] Published to URL

To complete publishing, change the source branch for this site to gh-pages.

Set the source branch at: URL

`

### `quarto check` Output

bash
[✓] Checking Quarto installation......OK
 Version: 1.0.37
 Path: /opt/quarto/bin

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
 Version: 3.10.4
 Path: /usr/bin/python3
 Jupyter: 4.10.0
 Kernels: python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
 Version: 4.2.0
 Path: /opt/R/4.2.0/lib/R
 LibPaths:
 - /home/eyayaw/R/x86_64-pc-linux-gnu-library/4.2
 - /opt/R/4.2.0/lib/R/library
 rmarkdown: 2.14

[✓] Checking Knitr engine render......OK

### `quarto tools check` Output

bash
[✓] Inspecting tools

Tool Status Installed Latest
chromium Not installed --- 869685
tinytex Update available v2022.05 v2022.08
WARNING: TeX Live not on path.

### Checklist

- [X] formatted your issue so it is easier for us to read?
- [ ] included a minimal, fully reproducible example in a single .qmd file? Please provide the whole file rather than the snippet you believe is causing the issue.
- [X] documented the quarto version you're running, by pasting the output from running `quarto check` in the "Quarto Check Output" text area?
- [X] documented the version of the quarto tools you're running, by providing the output from running `quarto tools check` in the "Quarto Tools Check Output" text area?
- [ ] documented the RStudio IDE version you're running (if applicable), by providing the value displayed in the "About RStudio" main menu dialog?
- [X] documented which operating system you're running? If on Linux, please provide the specific distribution as well.
- [X] upgraded to the latest version, including your versions of R, the RStudio IDE, and relevant R packages?

Publishing to `gh-pages` always uses the root because that's the default content location for GitHub Pages sites that use the `gh-pages` branch. Remember that the `gh-pages` branch created using `quarto publish` will have no other content in it so it's not really important that a subdirectory be used

yes i figured with render & custom publishing it would be possible, will try that approach


Question: [2.5] Audio delay on fresh install when running three parallel Kurento media servers?

@mokazemi Would you be able to do some more testing on your end to see if the audio is out of sync before you make either of those two changes (server time or `60:120:20`, then make one of the changes, and test again.

We would be very interested if you can do a specific before/after comparison of making only those these changes.

[2.5] Audio delay on fresh install when running three parallel Kurento media servers
I was installing BBB 2.5 on a new server and dealing with high audio delay (**audio and video where totally out of sync**).
I had copied `/etc/bigbluebutton/bbb-conf/apply-config.sh` file from the old server to the new one, without much changing it. There was called the function `enableMultipleKurentos` in it, based on here to run three parallel KMS.

I reinstalled it again and noticed that using `enableMultipleKurentos` function in `apply-config.sh` file may be causing this problem.
adding `disableMultipleKurentos` didn't solve the problem. So I ended up removing all files and installing again, without adding that function into apply-config fie. And it's solved now.

P.S. I'm not sure if it's been cause of the problem! I just decided to report it here, for more investigations.
Since I'm not currently able to reproduce it on another server.

**To Reproduce**
Steps to reproduce the behavior:
1. fresh installation of BBB 2.5
2. add `enableMultipleKurentos` to file `/etc/bigbluebutton/bbb-conf/apply-config.sh`
3. Run `sudo bbb-conf --restart`
4. Turn on audio and camera
5. Check on another device to see if it has any delay or not

Version: **BigBlueButton Server 2.5.1 (3020)**

I'm not sure, but I'd used `data="jitterbuffer_msec=60:120:20"` based on this.

Other than documented, looking at the actual implementation, the third parameter seems to be ignored: URL -> maxlen is set if there is a colon, but that's it. A second colon does not do anything.

Also, ` ` and ` ` do different things if I understand that correctly. The first one controls the RTP jitterbuffer within freeswitch, the second one sets parameters for the opus codec, which also has a jitterbuffer. They may both have an impact.

Thanks for mentioning this. I hadn't noticed the difference.
By the way, I wonder why the problem is solved after not calling `enableMultipleKurentos` function.
I thought it might do some overwrite that causes media to become out of sync, since I've read that BBB 2.5 uses mediasoup instead. (I'm not a developer, so it's just a guess!)

We changed the setting back to ` ` and could not reproduce the high-delay issue since then. Still not 100%, but we'll keep the `60:120` setting for now.

This jitterbuffer setting doesn't cause any problem for me. Since it's now 120 and everything is alright.
and when I was facing described problem, it was 60:120, and still not fixed (more than 2 seconds delay.)

Hello
We also have a relatively similar problem but without any change or modification to settings and configuration files.
After installing new fresh BBB 2.5.4 on a dedicated server (12 core + 64 ram) (also I tested before in vps ( 8 core + 16 ram) with the same issue):
- Sometimes when we have about 3-5 concurrent web came sharing with presentation enabled, we have unsynced sound for about 3-10 seconds delay from the video, and it may be continued for a while for some of the attendees or moderators from 1 minute to much more minutes.
- No special Errors in --status and --check but this one :
 URL
Regards

I have exactly this problem on dedicated server (32 core CPU + 16 GB Ram)

Can you check the audio delay on

 URL

and let us know if you encounter the same delay. You can use

 URL

to join with multiple users.

This does not always happen to everyone! But I have a session recorded on my server that shows it happening to one person in a session with 6 people.

we also have the delay Problem since 2.5.5. Sometimes it happens in meetings with only two users and some times with more.

I am also following this issue, because we have these problems in some conferences. We were able to find out that people suffering from high delay, at some time in the conference have had very short connection issues (e.g. high ping or high packet loss). This often was due to an unstable wifi connection. It made us curious, why the problems did not happen with 2.4, but with 2.5.x only.

What was the exact intention of URL

The documentation ( URL states: "The jitter buffer has three params that control its behavior: length, max length, and max drift. Length is the initial size of the jitter buffer in milliseconds. Max length is the upper bound for how big the jitter buffer can grow. [...]"

In the referenced commit, @ffdixon changed the JitterBuffer params from "60:120" (Initial: 60ms, Max: 120ms) to "120" (Initial: 120). Then max is not specified and can grow as big as it wants, or am I wrong? So my understanding is, that when there is no upper bound for the jitter buffer, everything works as expected. But when a client has a temporary problem with its network connection (e.g. wifi unstable), then the jitterbuffer might be increased so much, that there is a huuuge delay.

Thus, I do not understand, why the changes to the jitterbuffer have been made....

Hello. @ffdixon Today I did some experiments on what discussed here.

Here's my investigations:

**1. jitter buffer on `120` vs `60:120:20`**

 a) When it's set to `60:120:20` audio is a little bit cracky in case of packet loss, but there's much unusual delay.

 b) When it's set to `120` everything is normal for good connection. **But when there's packet loss**, There would be much **delay** in sending audio. Such when you make a sound, and after two or three seconds the name is indicated at the top of the screen and it receives to the other side. But the video receives without any delay. So it would be out of sync. consequently, people start interrupting each other.

* NOTE: I wasn't able to simulate packet loss. But it sounds the delay gradually appears in bad connections.
_________
**2. Server clock out of sync**
- First disable ntp with `timedatectl set-ntp no`
- Then change the time a few seconds with `sudo timedatectl set-time`
- Record something!
- Don't forget to enable ntp after experiment with `timedatectl set-ntp yes`

**Result:**
**There was nothing out of sync in the recording.** I'm not sure what was the problem before. Maybe the problem described here has been something else. I'll try to make more investigations if it happened again.

This is exactly what I wrote above. And it all makes sense regarding the issue.

Jitterbuffer will always add a delay, because it is a buffer that can be used when there are very short connection issues.
So you generally want the jitterbuffer to be as small as possible, but as long as it needs to be to overcome connectivity issues. Now, jitterbuffers may be dynamically increased by the application, so people with good connections have low latency, and people with bad connection have higher latency but uninterrupted audio/video.

Problem is: There has to be an upper bound for the jitterbuffer size. It does not make much sense to have a jitterbuffer (= delay) of 4 seconds in real-time communication. Instead, one would accept crackling audio sometimes (especially, if the connectivity issues are only very short, because of wifi or whatever)

So this is why I asked above, why @ffdixon changed the setting with "improving audio" as a commit message. It does not make any sense in my understanding.

I also noticed the delay gets shorter gradually when the connections become stable.
So I think that's somehow a correct behavior. But in some other applications (Like Google Meet) the audio plays slower in bad connection (instead of becoming cracky) and the delay disappears right after the connection becomes stable by playing audio a bit faster.

I opened a pull request to set a maximum jitterbuffer again. We are using "100:250" (100ms default, 250ms max) and it works well. These params are increased compared to the original ones @ffdixon changed (60:120).

Basically, if a client has a bad internet connection, the client will gradually increase the jitterbuffer value to be prepared for future connection problems. Jitterbuffers will always add delay.
This issue here is about people suffering from very sporadic connection problems: Not specifiying a maximum results in huge delays, even if a client has just a very short connection issue.

I can confirm that the problem occurs for users with packet loss. During a test meeting where it happened we checked the connection status and saw packet loss at the affected user.

We can confirm, that issues appeared directly after switching from 2.4 to 2.5.4. So we did a check on what changed and came across your jitterbuffer change. We reverted to 60:120 and the problem did not occur anymore. Thus, we had a look at the exact documentation and thought, that it might be a good idea to have the jitterbuffer increased to 100:250, so we are accepting a quarter of a second delay on bad connections. But we do not accept it to grow any further. In worst case this means that there will be crackling audio or some short interruptions. But it turned out that for the majority of the users the connection problems are very very short. So after the connection is OK again, there will be no big delay. This is more satisfying for the users.

Edit: I at first wrote with my personal account. This is why I deleted my first message here.

Hi, we also experienced the delay problem since we upgraded into 2.5.6. I hope URL will be included on 2.5.x soon.

we also have massive problems with BBB 2.5 and audio delay getting worse and worse with seconds what makes it unusable...

Suddenly video has too much delay with audio in the recording
**Describe the bug**
I'm facing a problem which I don't know the reason. In our today's session recording, I noticed the **video is too much out of sync** with the audio. Everything was alright in the live meeting (everything was in sync) but in the one-hour recording, video is more than 8 minutes behind!
There wasn't any problem before. It just appeared today. Nothing was changed in the server.

**Notes:**
- I thought it's related to #8815 but I've checked and the clock is correct (set with systemd-timesyncd with a near server)
- Rebooting the server and restarting BBB didn't help
- The problem seems to be with the video. It's too much early (Such that even the presenter says good-bye in the video and stops the recording, but the audio is correct).

**To Reproduce**
Steps to reproduce the behavior:
1. Start a meeting and join with audio
2. Turn on the camera and share your screen
3. wait for a few minutes
4. Start the recording
5. Stop the recording, then end the meeting

**Details**:

$ sudo bbb-conf --check

BigBlueButton Server 2.5.5 (3091)
 Kernel version: 5.4.0-125-generic
 Distribution: Ubuntu 20.04.5 LTS (64-bit)
 Memory: 12263 MB
 CPU cores: 8

/etc/bigbluebutton/bbb-web.properties (override for bbb-web)
/usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties (bbb-web)
 bigbluebutton.web.serverURL: URL
 defaultGuestPolicy: ALWAYS_ACCEPT
 svgImagesRequired: true
 defaultMeetingLayout: CUSTOM_LAYOUT

/etc/nginx/sites-available/bigbluebutton (nginx)
 server_name: vhall.scischool.ir
 port: 80, [::]:80
 port: 443 ssl

/opt/freeswitch/etc/freeswitch/vars.xml (FreeSWITCH)
 local_ip_v4: 130.185.75.197
 external_rtp_ip: 130.185.75.197
 external_sip_ip: 130.185.75.197

/opt/freeswitch/etc/freeswitch/sip_profiles/external.xml (FreeSWITCH)
 ext-rtp-ip: $${local_ip_v4}
 ext-sip-ip: $${local_ip_v4}
 ws-binding: 130.185.75.197:5066
 wss-binding: 130.185.75.197:7443

/usr/local/bigbluebutton/core/scripts/bigbluebutton.yml (record and playback)
 playback_host: vhall.scischool.ir
 playback_protocol: https
 ffmpeg: 4.2.7-0ubuntu0.1

/usr/share/bigbluebutton/nginx/sip.nginx (sip.nginx)
 proxy_pass: 130.185.75.197
 protocol: http

/usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml (Kurento SFU)
/etc/bigbluebutton/bbb-webrtc-sfu/production.yml (Kurento SFU - override)
 kurento.ip: 130.185.75.197
 kurento.url: ws://127.0.0.1:8888/kurento
 kurento.sip_ip: 130.185.75.197
 recordScreenSharing: true
 recordWebcams: true
 codec_video_main: VP8
 codec_video_content: VP8

/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml (HTML5 client)
/etc/bigbluebutton/bbb-html5.yml (HTML5 client config override)
 build: 2846
 kurentoUrl: wss://vhall.scischool.ir/bbb-webrtc-sfu
 enableListenOnly: true
 sipjsHackViaWs: true

/usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml (STUN Server)
 stun: stun.l.google.com:19302

# Potential problems described below

But since it was working properly till a few days ago, what is caused the problem?

hmm, missed "til a few days ago" part in the original description.
Still might have to do with the PR I mentioned since some of the issues it tackles are intermittent by nature.

It's an example of the problem:
 URL
(Note that the recording starts when the timer is 7 seconds. and in the video, it's shown that I press the stop and it says the meeting is no longer being recorded, but since the video is too behind, It's even shown after that I end the meeting!)

I think I was able to reproduce this issue with BBB 2.6 demo server. Sounds to be a bug! @prlanzarin

It is the result: URL

**steps:**
 - start the meeting
 - share your screen
 - wait for about a minute
 - start recording
 - after a little, stop the recording and close the room as fast as possible!

Had issues with 2.5.5 as well. Recording webcam and audio were extremely out of sync, and during the meeting everything seemed fine, mostly. For one test recording, for example, the webcam video stopped long before the audio did. Reverting to 2.5.4 was our solution.

I've got this issue too, on 2.5.5. Hour recording is about 2m50s out.
@kurjajuur666 did you simply install 2.5.4 using the script, or use a fresh OS install?

That's interesting and a good lead. Thanks for letting us known, I'll forward that internally.

I'm taking a look at the changes in #15149 - I'll let you know if I can figure out the cause. The difference seems to be surprisingly larger.

@mokazemi thanks for reproducing on the demo server - I'll be able to grab the data and logs from your meeting to help debug.

One of the changes made in #15149 was switching from using the "movie" filter input to read video files to using separate inputs to the ffmpeg command. My current theory is that a mistake was made in this conversion, and the seek point calculation is not being done correctly.

I have reprocessed the recording URL with the fix from #15702 manually applied on the test server. If you clear your browser cache and reload, you'll see that the correct portion of the screenshare video is now showing.

@kepstin, @mokazemi is the mentioned fix only for the building process of the recording or would it also fix the audio/video delay problem during the video conference? Since 2.5.5. we are facing delay problems during video conferences. Video is behind audio.

If I'm not mistaken, BBB deletes raw files of the recordings after 14 days, but for recordings in the last two weeks, you can rebuilt them again after applying the fix.
I don't have any ideas for recordings older than that (Maybe repairing by a video editing software to sync with audio)

yes rebuilt would work for recordings. The other problem we have is during video conferences. After one time the video and audio of a user is getting out of sync. There is a issue reported also here: URL
My hope was, that the above fix would be also the solution for the delay issue during meetings.

We also had that problem but it didn't happen again after:
- syncing the server time (Based on what discussed in #8815)
- Setting these values to `60:120:20` instead of `120` (based ot a suggestion discussed in #15172 But I don't know how it's effective)


Question: [Bug/Support]: "End of file during parsing" error: how to see whole log, including commands?

Thanks for taking the time to fill out a support ticket.

Yes. That does look like a circular dependency.
I've squashed that bug several times, so perhaps there's a case I missed.

Maybe they're related.
You can prevent the "too many open file" error by setting the `elpaca-queue-limit` option prior to processing any queues. e.g.

 emacs-lisp
(setq elpaca-queue-limit 30)

If you search the issue tracker there are other Windows users who have hit this limit.
I don't recall exactly where they ended up with that value, but I think it was closer to 12-20. Allegedly there are ways to allow more open file handles at the OS level, but I don't use Windows enough to give any advice on how to do it.

I would try:

1. saving `(setq elpaca-queue-limit 12)` in you init file just after the elpaca installer.
2. `M-x restart-emacs`

Then, in a fresh Emacs session, try another `elpaca-update-all` and see if the issue persists.

[Bug/Support]: "End of file during parsing" error: how to see whole log, including commands?
### Confirmation

- [X] I have checked the documentation (README, Wiki, docstrings, etc)
- [ ] I am checking these without reading them.
- [X] I have searched previous issues to see if my question is a duplicate.

### Elpaca Version

Elpaca 43ec2d8 grafted, HEAD -> master, origin/master, origin/HEAD
installer: 0.7
emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32)
 of 2024-04-08
git --version: git version 2.44.0.windows.1

### Operating System

Windows 11

### Description

I'm getting errors building a few packages. Not sure how to track them down because the log doesn't have the actual subprocess command executed to build:

vertico [MELPA|GNU-devel ELPA]
VERTical Interactive COmpletion

source: MELPA
url: URL
menu item recipe:
( :package "vertico"
 :repo "minad/vertico"
 :files (:defaults "extensions/vertico-*.el")
 :fetcher github
 :source "MELPA")
full recipe:
( :package "vertico"
 ;; Inherited from declaration.
 :files (:defaults "extensions/*")
 ;; Inherited from elpaca-order-functions.
 :depth 1
 :inherit t
 :protocol https
 ;; Inherited from elpaca-menu-item.
 :source "MELPA"
 :fetcher github
 :repo "minad/vertico")
dependencies:
 emacs >= 27.1
 compat >= 29.1.4.4
dependents: nil
installed version: 1.8 1def56a
statuses:
 (failed autoloads linking unblocked ref-checked-out unthrottled blocked queue-throttled unthrottled blocked queue-throttled queued)
files:
 $REPOS/vertico/extensions/vertico-buffer.el → $BUILDS/vertico/vertico-buffer.el
 $REPOS/vertico/extensions/vertico-directory.el → $BUILDS/vertico/vertico-directory.el
 $REPOS/vertico/extensions/vertico-flat.el → $BUILDS/vertico/vertico-flat.el
 $REPOS/vertico/extensions/vertico-grid.el → $BUILDS/vertico/vertico-grid.el
 $REPOS/vertico/extensions/vertico-indexed.el → $BUILDS/vertico/vertico-indexed.el
 $REPOS/vertico/extensions/vertico-mouse.el → $BUILDS/vertico/vertico-mouse.el
 $REPOS/vertico/extensions/vertico-multiform.el → $BUILDS/vertico/vertico-multiform.el
 $REPOS/vertico/extensions/vertico-quick.el → $BUILDS/vertico/vertico-quick.el
 $REPOS/vertico/extensions/vertico-repeat.el → $BUILDS/vertico/vertico-repeat.el
 $REPOS/vertico/extensions/vertico-reverse.el → $BUILDS/vertico/vertico-reverse.el
 $REPOS/vertico/extensions/vertico-suspend.el → $BUILDS/vertico/vertico-suspend.el
 $REPOS/vertico/extensions/vertico-unobtrusive.el → $BUILDS/vertico/vertico-unobtrusive.el
 $REPOS/vertico/vertico.el → $BUILDS/vertico/vertico.el
log:
 [2024-05-02 09:33:03] Package queued
 [2024-05-02 09:33:03] Continued by: elpaca--process
 [2024-05-02 09:33:03] elpaca-queue-limit exceeded
 [2024-05-02 09:33:03] Continued by: elpaca--finalize
 [2024-05-02 09:33:03] elpaca-queue-limit exceeded
 [2024-05-02 09:33:04] Continued by: elpaca--finalize
 [2024-05-02 09:33:04] Continued by: elpaca--configure-remotes
 [2024-05-02 09:33:04] Continued by: elpaca--checkout-ref
 [2024-05-02 09:33:04] Continued by: elpaca--dispatch-build-commands
 [2024-05-02 09:33:04] Continued by: elpaca--queue-dependencies
 [2024-05-02 09:33:04] No external dependencies
 [2024-05-02 09:33:04] Checking dependency versions
 [2024-05-02 09:33:04] Continued by: elpaca--check-version
 [2024-05-02 09:33:04] Linking build files
 [2024-05-02 09:33:04] Continued by: elpaca--link-build-files
 [2024-05-02 09:33:04] Build files linked
 [2024-05-02 09:33:04] Generating autoloads: c:/Users/garyo/AppData/Roaming/.config/emacs/elpaca/builds/vertico
 [2024-05-02 09:33:04] End of file during parsing
 [2024-05-02 09:33:04] Subprocess error (see previous log entries)

I set `elpaca-verbosity` to 100 but don't see anything more in that log.

I wonder if it could be related to this error regarding `generated-autoload-file` being redefined as dynamic?

% emacs --batch --eval '(let ((generated-autoload-file "autoloads.el")) (update-directory-autoloads "builds/vertico
"))'

Error: error ("Defining as dynamic an already lexical var" generated-autoload-file)
 (defvar generated-autoload-file nil "File into which to write autoload definitions.\nA Lisp file can set this in its local variables section to make\nits autoloads go somewhere else.\n\nIf this is a relative file name, the directory is determined as\nfollows:\n - If a Lisp file defined `generated-autoload-file' as a\n file-local variable, use its containing directory.\n - Otherwise use the \"lisp\" subdirectory of `source-directory'.\n\nThe autoload file is assumed to contain a trailer starting with a\nFormFeed character.")
 require(loaddefs-gen)
 byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\207" [require lisp-mode lisp-mnt cl-lib loaddefs-gen] 2)
 (update-directory-autoloads "builds/vertico")
 (let ((generated-autoload-file "autoloads.el")) (update-directory-autoloads "builds/vertico"))
 eval((let ((generated-autoload-file "autoloads.el")) (update-directory-autoloads "builds/vertico")) t)
 command-line-1(("--eval" "(let ((generated-autoload-file \"autoloads.el\")) (update-directory-autoloads \"builds/vertico\"))"))
 command-line()
 normal-top-level()
Defining as dynamic an already lexical var: generated-autoload-file

whereas this version without the `let` binding works for me:

% emacs --batch --eval '(progn (setq generated-autoload-file "autoloads.el") (update-directory-autoloads "builds/ve
rtico"))'
Package autoload is deprecated
 INFO Scraping files for autoloads.el...
 INFO Scraping files for autoloads.el...done

It looks to me like elpaca's `elpaca-generate-autoloads` uses the let-binding method, so maybe that's causing it but the error is suppressed, or it could be something else. Note that I am using a bleeding-edge emacs built from source.

I'm not 100% certain but doing this in my shell after the first elpaca pass with all the autoload failures seems to help:

garyo@tower1 (~/.config/emacs/elpaca/builds [main]) 4:38PM 4200=>
% for d in *(/); do emacs --batch --eval "(loaddefs-generate \"$d\" \"$d/$d-autoloads.el\")"; done
 INFO Scraping files for loaddefs...
 INFO Scraping files for loaddefs...done
 INFO Scraping files for loaddefs...
 INFO Scraping files for loaddefs...done
...

then I restart emacs and things seem to go better.

Sorry about that.
The entry is logged just after the process is kicked off.
In this case, the error beats the log to the punch.
That should be fixed on the master branch now.

Do you get the same error with a very simple configuration using `elpaca-test`?

How to run this test?

emacs-lisp
(elpaca-test
 :init (elpaca (vertico :wait t))
 (elpaca-test-log "#unique"))

Yes, it should be defvar'd in elpaca.el.

That may or may not work. When a package's build-dir is already on disk, Elpaca takes an optimistic path to reduce startup time. In that case only `elpaca--pre-built-steps` are run.
So it may just be skipping the issue. You could try a different operation like ` lpaca-rebuild`, which should attempt to regenerate the autoloads, after a restart to see if you hit the same error.

In this case, the error beats the log to the punch.
That should be fixed on the master branch now.

Hmm, no difference in the logs with elpaca 06ee3a6. Just "End of file during parsing" after "Generating autoloads".

Wow, I love your test harness!!! Here's the results:

 Test Case

How to run this test?

emacs-lisp
(elpaca-test
 :init (elpaca (vertico :wait t))
 (elpaca-test-log "#unique"))

 Host Env

 elpaca 06ee3a6 grafted, HEAD -> master, origin/master, origin/HEAD
 installer 0.7
 emacs GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-04-08
 git git version 2.44.0.windows.1

 Output

emacs-lisp

Error: end-of-file nil

 command-line-1(("--eval" "(setq debug-on-error t after-init-time nil)" "--eval" "(setq user-emacs-directory \"d:/tmp/elpaca.K94MA9) --eval (run-hooks" "'before-init-hook) -l ./init.el --eval (setq" "after-init-time" "(current-time)) --eval (run-hooks" "'after-init-hook) --eval (run-hooks" "'emacs-startup-hook) --eval (message" "\n" "Test" "Env\n) --eval (elpaca-version" "'message)"))

 command-line()

 normal-top-level()

End of file during parsing

From that output, I can see there's a missing escaped close-quote after the tmpdir. But I don't think it's getting to the point of trying to install vertico (or any of the other packages that fail -- about 50 fail for me, so it's not about the package itself). Also note this only happens on Windows. Maybe it's a path thing due to something like the "d:/" drive name?

The command seems to be OK (properly quoted) in `elpaca-test--make-process` :

("d:/emacs/emacs/bin/emacs" "--debug-init" "--batch" "-Q" #1="--eval" "(setq debug-on-error t after-init-time nil)" #1# "(setq user-emacs-directory \"d:/tmp/elpaca.iShFzl\")" "--eval" "(run-hooks 'before-init-hook)" "-l" "./init.el" "--eval" "(setq after-init-time (current-time))" "--eval" "(run-hooks 'after-init-hook)" "--eval" "(run-hooks 'emacs-startup-hook)" "--eval" "(message \"\n Test Env\n\")" "--eval" "(elpaca-version 'message)")

so I don't yet see where the trailing quote in the tmpdir is getting stripped off. (If that is indeed the problem.)

Ah, it was actually being over-written in the log due to me not accounting for DOS/Linux line ending differences in `elpaca--process-filter`. Should be fixed (for real this time) on master. I'm seeing the commands in the log in my Win10 VM now.

Thank you. It's been very handy for working out bugs.

Interesting! Indeed, I get the same error in my VM. I'm not sure what's causing that, but at least we've gotten to what seems like the root of the issue.

Here's my hypothesis:
Windows file-path separator is being interpreted as an escape character "\" in the printed command.
It escapes the closing quote for that string.
That seems to make sense with what we're observing.

Here's a test independent of Elpaca:

emacs-lisp
(make-process
 :name "*test*"
 :filter (lambda (process output) (message "%S" output))
 :sentinel (lambda (process event) (message "%S" event))
 :command (list (elpaca--emacs-path)
 "--batch" "--eval" (format "(print %S)" user-emacs-directory)))

On my Linux machine I get:

#
"
\"~/.emacs.d/\"
"
"finished
"

On Windows I get the error we're seeing.
So it's either a bug with how Emacs handles command line args,
or perhaps there's a better way to format the command string.
I'll try reporting upstream tomorrow and see if anyone has any insight.

Noting this here:

 URL

I noticed you've changed default-process-coding-system in your config.
However, I still get the same error with `emacs -q` on Windows.
Still unsure whether this is Elpaca's or Emacs's bug.

Apologies, must've not been running the test in the instance I thought I was last night.
With `emacs -q` I no longer get the error.

I concur, your non-elpaca test works for me with `emacs -Q`. I tried setting `(setq default-process-coding-system '(utf-8-unix . utf-8-unix))` before running the test in `emacs -Q` and it still succeeds.

There is some very hairy quoting code in emacs's `w32proc.c` but at the moment I can't debug into that.

Good idea. I'll try and isolate a minimal reproduction case.

Once we have a solid reproduction case, if I'm confident it's not something on Elpaca's end, I'll open a bug report upstream.
Eli uses Windows, so he may have some knowledge of the inner workings there.

Good catch and sorry about that!
I refactored `elpaca-info` to make it easier to use in tests, and as you've noticed, missed that call site in `elpaca-ui-info`.
Should be fixed on master now.

You can add the "#verbosity" search tag to your search query to temporarily set `elpaca-verbosity` to a maximum in the log buffer.
The `elpaca-info` buffer should normally display the whole log, too.

I recently refactored `elpaca-log` to make it easier to use from lisp programs as well.
The following should write the full log to a file:

 emacs-lisp
(with-temp-buffer
 (insert (elpaca-log ".*"))
 (write-file "/tmp/test.log"))

I seem to have a fix for this issue! Since forever (maybe 15 or 20 years anyway), I've had this in my init file: `(setq w32-quote-process-args ?\")`
If I remove that, my elpaca setup runs to completion.
I have no idea why I had to have that, all those years ago; I expect the default value of `t` is fine.
I also can't explain why you *can* repro it, unless you have the same setting.

Aha! I figured it might've been a user option.

I was running your config on Windows :).

Thank you!
Let me know if that also takes care of URL for you.

[Bug/Support]: git-commit blocked on magit, and magit blocked on git-commit: circular dep?
### Confirmation

- [X] I have checked the documentation (README, Wiki, docstrings, etc)
- [ ] I am checking these without reading them.
- [X] I have searched previous issues to see if my question is a duplicate.

### Elpaca Version

Elpaca 43ec2d8 grafted, HEAD -> master, origin/master, origin/HEAD
installer: 0.7
emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32)
 of 2024-04-08
git --version: git version 2.44.0.windows.1

### Operating System

Windows 11

### Description

Doing `elpaca-update-all` on my Windows machine, with recent Emacs 30 and latest elpaca, I have what seems like a circular dependency that prevents elpaca from finishing: magit depends on git-commit, and git-commit is inside the magit repo so is blocked on magit. I'm not sure how to proceed.

git-commit blocked Waiting for mono-repo magit 27.152611
magit-section blocked Waiting for mono-repo magit 27.152635
magit blocked Blocked by: (git-commit)

(I'm also having unrelated issues with "too many open files" errors, still working on those, but wanted to report this one.)

This specific issue seems to be gone now since I applied a user fix (see #303) but I'm still getting an issue with transient; magit-commit requires a very recent version of transient (>=20240421) but elpaca doesn't install that, so the magit-commit install fails.
The log is:

git-commit [MELPA|NonGNU-devel ELPA]
Edit Git commit messages.

source: MELPA
url: URL
menu item recipe:
( :package "git-commit"
 :fetcher github
 :repo "magit/magit"
 :files ("lisp/git-commit.el" "lisp/git-commit-pkg.el")
 :old-names (git-commit-mode)
 :source "MELPA")
full recipe:
( :package "git-commit"
 ;; Inherited from elpaca-order-functions.
 :depth 1
 :inherit t
 :protocol https
 ;; Inherited from elpaca-menu-item.
 :source "MELPA"
 :old-names (git-commit-mode)
 :files ("lisp/git-commit.el" "lisp/git-commit-pkg.el")
 :repo "magit/magit"
 :fetcher github)
dependencies:
 emacs >= 26.1
 compat >= 29.1.4.5
 transient >= 20240421
 with-editor >= 20240415
dependents:
 magit
installed version: 3.3.0.50-git f7cba11
statuses:
 (failed unblocked blocked continued-dep queued)
files:
 $REPOS/magit/lisp/git-commit-pkg.el ! $BUILDS/git-commit/git-commit-pkg.el
 $REPOS/magit/lisp/git-commit.el ! $BUILDS/git-commit/git-commit.el
log:
 [2024-05-08 12:20:41] Package queued
 [2024-05-08 12:20:41] Continued by: elpaca--continue-dependency
 [2024-05-08 12:20:41] Continued by: elpaca--dispatch-build-commands
 [2024-05-08 12:20:41] Queueing Dependencies
 [2024-05-08 12:20:44] Continued by: elpaca--check-status
 [2024-05-08 12:20:44] Unblocked by: with-editor
 [2024-05-08 12:20:44] Checking dependency versions
 [2024-05-08 12:20:44] transient installed version (20240408) lower than min required 20240421
 [2024-05-08 12:20:44] Continued by: elpaca--check-version

If I do `(use-package transient)` before `(use-package magit)` it works, but I don't think I should need to do that -- maybe it's due to the older version of transient being built-in, so elpaca doesn't want to silently override it on my behalf?

Glad to hear it.

You're correct. Currently, Elpaca will not install a built-in package unless you explicitly request it.
There's a feature request for automatically updating built-in packages and some previous discussion here: URL

What's specifically happening in this situation is:

git-commit requires transient with a "YYYYMMDD" timestamp version (which MELPA introduced, and very few package authors use to declare dependencies).
Since transient is built-in, we have no reliable way of getting the exact date it was last modified.
Elpaca's compromise is to maintain an alist of Emacs release dates for stable versions and fall back to `emacs-build-time` for unstable versions when available.
That value is stored in `elpaca-core-date` which is used as the timestamp version for any built-in package.
My hunch is that your `elpaca-core-date` is "20240408" considering:

emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-04-08

Rebuilding Emacs should bump that value and transient will pass the version check.
It's also possible to work around the issue by lying to Elpaca about the version date (via the `:version` recipe keyword), or disabling the check altogether, but that may lead to breakage.


Question: Evaluate data quality when saving and loading feather and parquet files?

#332 was accepted and closed with a caveat. Please see final comment with implementation notes and testing instructions.

Evaluate data quality when saving and loading feather and parquet files
Evaluate add difference in resulting loaded dataframe when using to read_csv and to_csv versus comparable feather and parquet functions:

- URL
- URL
- URL
- URL

This can be tested with these CSV files:

- URL
- URL
- URL
-

import os
import pandas as pd
import pyarrow as pa

import openpolicedata as opd

datasets = [('State Patrol', 'Arizona', 'STOPS', 'MULTIPLE'),
 ('New York City', 'New York', 'PEDESTRIAN STOPS', 2014),
 ('Chandler', 'Arizona', 'CALLS FOR SERVICE', 'MULTIPLE')]

for sname, state, tbl, year in datasets:
 src = opd.Source(sname, state)

 t = src.load(tbl, year)

 df = t.table

 df.to_feather('out.feather')
 df_comp = pd.read_feather('out.feather')
 os.remove('out.feather')

 assert df.equals(df_comp)

 df.to_parquet('out.parquet')
 df_comp = pd.read_parquet('out.parquet')
 os.remove('out.parquet')

 assert df.equals(df_comp)

The above code gives the following error:

Exception has occurred: ArrowTypeError
("Expected bytes, got a 'int' object", 'Conversion failed for column perstop with type object')
 File "C:\Users\matth\repos\openpolicedata\opddev\test_feather_parquet_accuracy.py", line 17, in
 df.to_feather('out.feather')
 ~~~~~~~~~~~~~^^^^^^^^^^^^^^^
pyarrow.lib.ArrowTypeError: ("Expected bytes, got a 'int' object", 'Conversion failed for column perstop with type object')

It is due to a column with mixed data types of strings and integers. This type of thing is common in some datasets where the data quality is imperfect.

However, we could catch the error and notify the user what the issues is and direct them to use CSV file output instead

The quality of the data when reading out and in with feather/parquet has no issues.

There are challenges when writing data that to_csv can deal with.

There are issues if there are columns with mixed data types. A known reason that mixed data types occur is that we don't use the low_memory=False option in calls to pd.read_csv in csv_class.py. This results in dtypes being processed and set in chunks for efficiency but occasionally, at the cost of having a columns that has both numeric and string values. In these cases, if low_memory=False, those same columns would have been read in as strings instead of strings and numbers. I recommend the following to handle this case:
- Include a mixed input that defaults to False
- If mixed is False, function fails if mixed dtypes exist
- If mixed is True, function finds all mixed dtype columns and converts them to strings prior to writing the data out

Another issue occurs when there are unknown characters (or bytes) in the data. Pandas to_csv has a errors="surrogateescape" option that handles these values. This input is used in to_csv in data.py. to_feather and to_parquet don't have this options. I recommend catching the unicode errors and displaying a message instructing that they will need to use to_csv.

Testing only 3 datasets was sufficient to find the 2 above issues. There could be other issues. I'm going to close this issue and recommend continuation of #330 with the caveat that many more datasets should be run through the final candidate version of the data prior to acceptance into the code.

import os
import pandas as pd
import pyarrow as pa
import re

import openpolicedata as opd

datasets = [('New York City', 'New York', 'PEDESTRIAN STOPS', 2014),
 ('State Patrol', 'Arizona', 'STOPS', 'MULTIPLE'),
 ('Chandler', 'Arizona', 'CALLS FOR SERVICE', 'MULTIPLE')]

for sname, state, tbl, year in datasets:
 print(f'Running {sname}')
 src = opd.Source(sname, state)

 t = src.load(tbl, year)

 df = t.table

 try:
 df.to_feather('out.feather')
 except pa.lib.ArrowTypeError as e:
 print(f"Converting mixed types: {sname}")
 # pyarrow can't handle mixed data types. Convert columns to str so they will save
 mixed_dtypes = {c: dtype for c in df.columns if (dtype := pd.api.types.infer_dtype(df[c])).startswith("mixed")}
 assert [x=='mixed-integer' for x in mixed_dtypes.values()]

 for c in mixed_dtypes.keys():
 df[c] = df[c].apply(str)

 df.to_feather('out.feather')
 except UnicodeEncodeError:
 print('Failure due to unicode error. Advise csv usage')
 continue

 df_comp = pd.read_feather('out.feather')
 os.remove('out.feather')

 assert df.equals(df_comp)

 df.to_parquet('out.parquet')
 df_comp = pd.read_parquet('out.parquet')
 os.remove('out.parquet')

 assert df.equals(df_comp)

Explore using alternatives to CSV files for import and export of data from local file system
This is the parent task of several sub-tasks to evaluate and potentially implement this feature. If interested in taking on this issue, please request to be assigned to a sub-task.

In `data.py`, OPD provides `load_from_csv` and `to_csv` capabilities for loading and storing files locally. Feather and parquet files may be more efficient for storing dataframes (See here).

This task involves evaluating alternatives and if there are no issues found, implement comparable functions to `load_from_csv` and `to_csv` for the new file types.