Flowy implemention

@aelassas the Flowvy implementation in the v5.3 looks great.
I have tried it out and the new version, and over all it working GREAT.... very good work.
I have only found minor improvements missing.

When task i created, you cannot change header task details like, type etc, but you can enter it, and works fine when creating the new task.
JSON is missing ExecutionGraph code
Flowy not yet ready for designing ExecutionGraph code.
Browse / search / Cannot search for task id.

Else then it's looking great and much better than the standard up-to v.5.2
/Cheers

@janborup Thanks for your feedback. Glad that you liked the v5.3. Regrding flowy, yes it is not ready for designing the execution graph for the moment. I will take in consideration your feedback in the v5.4.

@janborup I added the execution graph to the json view. Can you check it and tell me how you find it?

Hi @aelassas
The Execution Graph is working fine now and showing in JSON, and i like the Blockly Graph implementation.
GREAT.

Now a follow decision (Mayby it should be in a new topic)
What about implementation of the LocalVariables of a workflow?

Right now this is only able, in XML/JOSN, but should this be made in the designer by Flowy or Blockly ?
If you can made a decision, I could make a mock-up for it, if you like to.

@janborup Please open a new issue for this and tag it as enhancement. We can edit local variables in the editor but not in the designer yet. I think I will add them in the right panel of workflow settings.

Extra Flowy designer implementations.

Suport for Add multiple settings per workflow task.

@janborup I added multiple settings to designer. Can you test it and tell me how you find it?

I have tested the support for multible settings, and this works fine. Check 👌
A little enhancement to this topic.

When using ex. Selectfile-setting in a task-setting to get the task-number, you cannot see the numbers of the other Flowy tasks, so simply nummerize the tasks in Flowy.

@janborup All done. I've just updated the designer with the little enhancement.

Thanks the Task-Id, does the trick. 👍
New issue:
There is a layout error in "Mobile"-view, so when entering the designer, the Right-side Workflow-settings popin - is stuck, it's showing even it is slide in or slide out.
Don't think it's new layout error, saw it yesterday also.
Desktop view works fine.
Here is mobile view in Chrome:

Here is mobile view on iPhone mobile

@janborup I've fixed mobile layout issues in the designer. Can you try again an let me know if it is working fine now?

Yep... the Position: fixed, solved the issue :-)
I don't see anymore issues in the designer, only some small CSS tidy up like aligning the checkboxes in the settings both in desktop/mobile (see above), but that can always be done.
Case closed.


ci(release): update release steps

:tada: This PR is included in version 1.5.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add more syllogism examples

Description
This PR enhances the tasks/syllogism-reasoning.md file by:

Adding 23 new, modern examples of valid syllogisms, covering all 24 valid syllogistic forms more info.
Providing diverse, contemporary contexts.

NOTE: the previous two examples were for the same syllogistic form. I kept the first original one.

Hmmm... normally so many examples would seem redundant - as these aren't met to be datasets. But given there are 24 different forms... @teknium1 what do you think?

@N8python @teknium1 Let me see if I understand the final goal correctly, these examples are to be given to a model and after that, the model will generate much more synthetic examples. If that is the case, I definitely think that if we have only two examples that are representing the same form, the model will simply generate most likely many variations of this one. Probably in this case all forms will produce more diverse examples. However, there is always the risk the model will get confused and start mixing them etc if it is not very capable. Let me know if you need some help to try to generate some examples using some relatively small model (e.g. mistral-nemo 12B) and verify some sample manually.

@N8python @teknium1 Let me see if I understand the final goal correctly, these examples are to be given to a model and after that, the model will generate much more synthetic examples. If that is the case, I definitely think that if we have only two examples that are representing the same form, the model will simply generate most likely many variations of this one. Probably in this case all forms will produce more diverse examples. However, there is always the risk the model will get confused and start mixing them etc if it is not very capable. Let me know if you need some help to try to generate some examples using some relatively small model (e.g. mistral-nemo 12B) and verify some sample manually.

Nope just used as a reference document for researchers and developers. They can use it for that if they want but given that there is not a difficulty or quality requirement, I wouldn't recommend it.
Either way, it's fine and I'll merge


typo in function name

There seems to be a typo in the function  prototype.
On the page it is listed as
int Networking_TimeSync_EnableCustomNTP(const char *primaryNtpServer, const char *secondaryNtpServer, Networking_NtpOption option);
But it should be
int Networking_TimeSync_EnableCustomNtp(const char *primaryNtpServer, const char *secondaryNtpServer,                                    Networking_NtpOption option);
This is not a major issue, but the "NTP" should be "Ntp"

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 252e20d6-5fd7-bc7d-dacd-ed100234a649
Version Independent ID: 1ee3e341-1220-dfd0-bf31-16c73555fdee
Content: Networking_TimeSync_GetCustomNTP function - Azure Sphere
Content Source: AzureSphere/articles/reference/applibs-reference/applibs-networking/function-networking-timesync-enablecustomntp.md
Product: azure-sphere
GitHub Login: @DonnaHill007
Microsoft Alias: azurespheredocs

@Omakas  Thanks for your contribution, I've addressed this issue in PR: https://github.com/MicrosoftDocs/Azure-Sphere-Docs-pr/pull/266
The changes should be live EOD or tomorrow. In future, if you see any minor bug fixes in the doc, feel free to click on the edit button and submit a PR to update. we love to take community contributions.
@DonnaHill007 Could you please review and approve the pull request?

@Omakas This has been fixed.


[Bug Report] I am hosting with bot-hosting.net but i get an error in the terminal form jmmusicbot can someone look at this

Bug Description
container@pterodactyl~ Server marked as starting...
container@pelican~ java -version
openjdk version "21.0.5" 2024-10-15 LTS
OpenJDK Runtime Environment Temurin-21.0.5+11 (build 21.0.5+11-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.5+11 (build 21.0.5+11-LTS, mixed mode, sharing)
container@pelican~ java -Dterminal.jline=false -Dterminal.ansi=true -jar "${JARFILE}"
[11:46:45] [INFO] [JMusicBot]: Loaded config from /home/container/config.txt
[11:46:45] [INFO] [Settings]: serversettings.json loaded from /home/container/serversettings.json
[11:46:51] [ERROR] [JMusicBot]: Could not start GUI. If you are running on a server or in a location where you cannot display a window, please run in nogui mode using the -Dnogui=true flag.
[11:46:54] [INFO] [JDA]: Login Successful!
[11:46:54] [INFO] [WebSocketClient]: Connected to WebSocket
[11:46:55] [INFO] [JDA]: Finished Loading!
[11:48:10] [ERROR] [SignatureCipherManager]: Problematic YouTube player script /s/player/3bb1f723/player_ias.vflset/de_DE/base.js detected (issue detected with script: no actions match). Dumped to /tmp/lavaplayer-yt-player-script13308335193134684711.js
[11:48:10] [ERROR] [LocalAudioTrackExecutor]: Error in playback of pFEDBewcfks
com.sedmelluq.discord.lavaplayer.tools.FriendlyException: Something broke when playing the track.
at com.sedmelluq.discord.lavaplayer.tools.ExceptionTools.wrapUnfriendlyExceptions(ExceptionTools.java:45)
at com.sedmelluq.discord.lavaplayer.track.playback.LocalAudioTrackExecutor.execute(LocalAudioTrackExecutor.java:121)
at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$executeTrack$2(DefaultAudioPlayerManager.java:339)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.IllegalStateException: Must find action functions from script: /s/player/3bb1f723/player_ias.vflset/de_DE/base.js
at dev.lavalink.youtube.cipher.SignatureCipherManager.extractFromScript(SignatureCipherManager.java:235)
at dev.lavalink.youtube.cipher.SignatureCipherManager.getCipherScript(SignatureCipherManager.java:195)
at dev.lavalink.youtube.clients.skeleton.NonMusicClient.loadTrackInfoFromInnertube(NonMusicClient.java:74)
at dev.lavalink.youtube.clients.skeleton.StreamingNonMusicClient.loadFormats(StreamingNonMusicClient.java:35)
at dev.lavalink.youtube.track.YoutubeAudioTrack.loadBestFormatWithUrl(YoutubeAudioTrack.java:183)
at dev.lavalink.youtube.track.YoutubeAudioTrack.processWithClient(YoutubeAudioTrack.java:109)
at dev.lavalink.youtube.track.YoutubeAudioTrack.process(YoutubeAudioTrack.java:71)
at com.sedmelluq.discord.lavaplayer.track.playback.LocalAudioTrackExecutor.execute(LocalAudioTrackExecutor.java:109)
... 4 common frames omitted
[11:48:10] [ERROR] [AudioHandler]: Track pFEDBewcfks has failed to play
com.sedmelluq.discord.lavaplayer.tools.FriendlyException: Something broke when playing the track.
at com.sedmelluq.discord.lavaplayer.tools.ExceptionTools.wrapUnfriendlyExceptions(ExceptionTools.java:45)
at com.sedmelluq.discord.lavaplayer.track.playback.LocalAudioTrackExecutor.execute(LocalAudioTrackExecutor.java:121)
at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$executeTrack$2(DefaultAudioPlayerManager.java:339)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.IllegalStateException: Must find action functions from script: /s/player/3bb1f723/player_ias.vflset/de_DE/base.js
at dev.lavalink.youtube.cipher.SignatureCipherManager.extractFromScript(SignatureCipherManager.java:235)
at dev.lavalink.youtube.cipher.SignatureCipherManager.getCipherScript(SignatureCipherManager.java:195)
at dev.lavalink.youtube.clients.skeleton.NonMusicClient.loadTrackInfoFromInnertube(NonMusicClient.java:74)
at dev.lavalink.youtube.clients.skeleton.StreamingNonMusicClient.loadFormats(StreamingNonMusicClient.java:35)
at dev.lavalink.youtube.track.YoutubeAudioTrack.loadBestFormatWithUrl(YoutubeAudioTrack.java:183)
at dev.lavalink.youtube.track.YoutubeAudioTrack.processWithClient(YoutubeAudioTrack.java:109)
at dev.lavalink.youtube.track.YoutubeAudioTrack.process(YoutubeAudioTrack.java:71)
at com.sedmelluq.discord.lavaplayer.track.playback.LocalAudioTrackExecutor.execute(LocalAudioTrackExecutor.java:109)
... 4 common frames omitted
Steps to Reproduce
i dont know mayby run it on bot-hosting.net
Expected Result
It joins the call says its playing but does not work
Debug Output
i run a java node on bot-hosting.net
Additional Info
No response
Checklist

[X] I have looked for information about this within the documentation
[X] I have searched for similar issues on the issues page
[X] I am using an official release from the releases page

JMusicBot Version
the newest one

Duplicate of #1588


virtual memory exhausted: Cannot allocate memory and Failed running ["make -j4"]

I'm running into the Failed running ["make -j4"] error due to virtual memory exhausted: Cannot allocate memory.
I have an i5 processor machine with 16GB ram running arch linux. The folder node-8.3.0-1.5.0 is about 1GB.
And in the tmp dir there's a folder called __work_dir__/ (500mb) that contains the __enclose_io_memfs__/
I closed all of the other processes like browsers,ide when running nodec.
I couldn't find the file enclose_io_memfs.o. It was perhaps already gone by the time the error was thrown
#ls /home/user/tmp/node-8.3.0-1.5.0/out/Release/obj.target/enclose_io_libsquash/deps/libsquash/sample/enclose_io_memfs.o

ls: cannot access '/home/user/tmp/node-8.3.0-1.5.0/out/Release/obj.target/enclose_io_libsquash/deps/libsquash/sample/enclose_io_memfs.o': No such file or directory

All of the prerequisites are latest:
gcc 7.2.0-3
SquashFS Tools 4.3
clang 5.0.0-1
GNU Make 4.2.1
Would you please figure out the problem?
g++ '-DV8_GYP_BUILD' '-DV8_TARGET_ARCH_X64' '-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT' '-Dv8_promise_internal_field_count' '-DV8_INTL_SUPPORT' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DUCONFIG_NO_SERVICE=1' '-DUCONFIG_NO_REGULAR_EXPRESSIONS=1' '-DU_ENABLE_DYLOAD=0' '-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=0' '-DUCONFIG_NO_BREAK_ITERATION=0' -I../deps/v8 -I../. -I/home/user/tmp/node-8.3.0-1.5.0/out/Release/obj/gen -I../deps/v8/include -I../deps/icu-small/source/i18n -I../deps/icu-small/source/common  -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -fdata-sections -ffunction-sections -O3 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/user/tmp/node-8.3.0-1.5.0/out/Release/.deps//home/user/tmp/node-8.3.0-1.5.0/out/Release/obj.target/v8_base/deps/v8/src/inspector/v8-console-agent-impl.o.d.raw   -c -o /home/user/tmp/node-8.3.0-1.5.0/out/Release/obj.target/v8_base/deps/v8/src/inspector/v8-console-agent-impl.o ../deps/v8/src/inspector/v8-console-agent-impl.cc
virtual memory exhausted: Cannot allocate memory

make[1]: *** [deps/libsquash/enclose_io_libsquash.target.mk:97: /home/user/tmp/node-8.3.0-1.5.0/out/Release/obj.target/enclose_io_libsquash/deps/libsquash/sample/enclose_io_memfs.o] Error 1
make[1]: *** Waiting for unfinished jobs....
rm 76915d34a7c911eded1b8688b6af2b8d62d67192.intermediate
make: *** [Makefile:76: node] Error 2
Failed running ["make -j4"]

you should check if swap file is enabled for your Linux dist.

@cnddu
Yes, I have a swap partition. I just checked the memory usage. It was through the roof when nodemc was running! I have 4gb swap space + 16GM RAM and it's still not enough.

try bellow options:

setup 16GB swap space
do not use -j4 but -j1

This didn't used to happen earlier using the same server
I have 7GB RAM and 7GB Swap space and getting the same error

@stonecold123 The problem is because of possible output file like a.out is in the same folder as project.
I changed the location of output file to outside of project , removed any output file from the project directory and its fixed

Agh this fix got my hopes up, but unfortunately it didn't make a difference.

Try adding an option --disable-fileinfo after the configure command is a way to solve this issue.

How do you do that?

Try adding an option --disable-fileinfo after the configure command is a way to solve this issue.

How do you do that?

Storing file info may waste many virtual memory, just disable it is fine.
Add the option --disable-fileinfo on running configure command:
./configure --disable-fileinfo

where and when do you run ./configure?

where and when do you run ./configure?

yes.


Inheritance bug

Add support in Inheritance (Open API sepc 2.0)
Replace parameter validation - remove swagger-paramaters dependency

Coverage remained the same at 100.0% when pulling 5be4e6a6ded0f02768ef3e02d1787c0df2f97225 on inheritance-bug into 2b43ff2027de2b0757c6f82b5b71c17a0a82a9a4 on master.


publish views lunar livewiretables component, but the changes I made do not seem to take effect

Lunar version: 0.8
Laravel Version: 9.52.16
PHP Version: 8.2.15
Database Driver & Version: posgresql - 16

After publishing 'lunar.livewiretables.components,' the files were successfully published in the 'views/vendor/lunar' directory. However, the changes I made do not seem to take effect.

What changes were you trying to make? Did you clear the view cache?

Closing due to inactivity, if this is still a problem feel free to reopen with more information on the issue or how to reproduce


Decorate class.

Hello, dear reviewer👋,
This Pull Request is created for the review of the implementation of the Decorator pattern this Ruby Project. Here are the main features added and the files involved:

Decorator Pattern: This pattern has been employed to modify the behaviour of Person objects in the project. Two decorators have been created: CapitalizeDecorator and TrimmerDecorator.

Files Involved: nameable.rb, decorator.rb, capitalize_decorator.rb, trimmer_decorator.rb

Nameable Interface: A new interface has been created that requires the implementation of the correct_name method.

File Involved: nameable.rb

Person Class: The Person class now includes the Nameable class and implements the correct_name method.

File Involved: person.rb

CapitalizeDecorator Class: A new decorator that capitalizes the name of a Person object.

File Involved: capitalize_decorator.rb

TrimmerDecorator Class: A new decorator that trims the name of a Person object to a maximum of 10 characters.

File Involved: trimmer_decorator.rb

Testing Instructions: Please run the main.rb file which will demonstrate the functionality of the decorators. It creates a Person object and applies the decorators, printing out the results.

File Involved: main.rb

If there are any issues or further requirements needed, feel free to let me know. I appreciate your time and consideration.
Thank you,
Julio Quezada.

Thank you very much for your valuable time.


Enable Auditlog Services

Depends on https://github.com/SURFnet/Stepup-Middleware/pull/76

@rjkip lookie lookie

:+1:


"Support Multiple Domain" tasks should be separated using Azure AD Connect and directory configure AD FS

Issues

It should be separated how to setup multiple domain using Azure AD Connect or run Powershell commands for directory setting up AD FS.
Azure AD Connect has been updated. Screenshot has been already different.

details
For almost customers especially who have not edit claims, it is not needed to run powershell scripts that Update-MsolFederatedDomain and Convert-MsolDomaintoFederated.
It is easy for them to just run Azure AD Connect and add Federated Domain.
I recommend to describe two ways to enable multiple domain on this article. Using Azure AD Connect or directory setting up AD FS using Powershell command.
using Azure AD Connect, we can now add new custome domain at [Manage federation] > [Federation an Azure AD domain]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 081729e5-959f-d8c2-de1b-b035c6dbc8fb
Version Independent ID: c93eda68-5b52-04bf-fca2-53bb7eba178a
Content: Azure AD Connect Multiple Domains
Content Source: articles/active-directory/hybrid/how-to-connect-install-multiple-domains.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@watahani Thank you for your feedback . We will engage the content team to have this suggestion reviewed.

@billmath Could you please take a look at this issue and have the suggestion reviewed for content update?

@watahani Thank you for the feedback.  I have created a backlog work item for this and will be working on this in the coming months.  I will send a follow-up once this has been updated.  Thanks!
#please-close


Development Subscription Migration

Which issue this PR addresses:

Fixes
What this PR does / why we need it:

Test plan for issue:

Is there any documentation that needs to be updated for this PR?

A few things around keyvault needed changing in RP. This is due to the fact that we cannot have two keyvaults with the same name. our current subscription (while in a different tenant) conflicts with the new subscription.

Closed in favor of https://github.com/Azure/ARO-RP/pull/2072 due to some issues, i was not able to comment on my own PR


Lightbox not resizing to portable devices

The poorman lighbox does not expand properly for mobile devices ....
http://www.elkarte.net/community/index.php?topic=4007.0;topicseen

fixed in  #2704


Prevent ad slots between posts from jumping around

Currently, ad slots between posts are calculated by considering only the currently rendered posts (PostStream children):
https://github.com/FriendsOfFlarum/ads/blob/44f401a207ef2ca39684367a4339a7b6ea7b9bb2/js/src/forum/addAdBetweenPosts.js#L13-L26
This has the side effect that when new posts are loaded "above", ad slots are recalculated and might be positioned differently, since the code assumes that the first post of the discussion is the first vnode in the stream.
One solution to this would be to use the actual post number (post.attrs['data-number']) instead of the index of the vnode (i), and the total posts count (this.count()) instead of the total number of loaded comments (commentPosts.length). The main difference would be that all kinds of posts would be taken into account for the "between" count, instead of only the comment posts. I'm not even sure if this is better or worse in terms of where you would expect ads to be placed... But it is a solution.

Thanks for the report.
Post numbers alone probably won't solve the issue since we can't rely on numbers to be subsequent or even be in order.
The best solution would probably to read the full list of post IDs for the discussion, which is already loaded by the scrubber, calculate the positions based on that list, then identify the posts by their IDs in the stream and use that to identify where to insert ads.

Hi Clark!

we can't rely on numbers to be subsequent

You're right, especially with hidden/deleted posts, I didn't consider that.

or even be in order

Could this actually happen? I know that the post stream is sorted by post creation date (not sure why honestly), but the post number is still incremented at each post and recomputed when you split/merge. It doesn't seem to behave very differently from the autoincrementing post ID, unless I'm missing something.
Anyway, you're right that the post ID solution is better, at least for the first reason above.

Could this actually happen?

At this moment, with the existing community extensions, and from a forum that started fresh with Flarum, probably very unlikely.
My own Author Change extension can be used to create such anomalies. Other extensions might as well.
This can also happen with faulty imports. I'm actually dealing with this problem right now and creating https://github.com/migratetoflarum/renumber-posts to rectify Flarum databases.
Not sure when we'll be able to implement this into Ads however :grimacing:

Ok! I'll probably send a PR at some point, it doesn't seem hard to implement


Invalid get index 'data'  on function "connect_to_eventsub"

In file addons/gift/gift_node.gd, on line 454 (last line of the following snippet, function connect_to_eventsub)
add_child(request)
request.request("https://api.twitch.tv/helix/eventsub/subscriptions", ["User-Agent: GIFT/3.0.0 (Godot Engine)", "Authorization: Bearer " + token["access_token"], "Client-Id:" + client_id, "Content-Type: application/json"], HTTPClient.METHOD_POST, JSON.stringify(data))
var reply : Array = await(request.request_completed)
var response : Dictionary = JSON.parse_string(reply[3].get_string_from_utf8())
print("Now listening to %s events for broadcaster_id %s." % [response["data"][0]["type"], response["data"][0]["condition"]["broadcaster_user_id"]])

I get Invalid get index 'data' (on base: 'Dictionary').
The response was to the request was { "error": "Forbidden", "status": 403, "message": "subscription missing proper authorization" }, which does not have the data key, which causes the error.
Also, this code assumes the EventSub subscription process always succeeds, and does not handle any other outcome, which is problematic.

Twitch changed the API regarding the channel.follow event. I will put the event subscription in the hands of the user instead of handling all event versions by GIFT. There will only be a single 'event' signal with the type of event and data instead of a signal for each event.
Events will have to be subscribed to by specifying the event name, API version and conditions and emit all related data, which will not require me to update GIFT on every API change in the future.
Will add a check for failure of the subscription as well, I simply forgot <3
Thanks!


Switch test to typescript ?

Maybe switch the test file to typescript, to not use the build files to test.

After short evaluation this is not needed.

I will do this ! 😆

Implemented with Merge #13


Reusable log interceptor

Pull Request Test Coverage Report for Build 1027

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 90.929%

Files with Coverage Reduction
New Missed Lines
%

storage/postgres/storage.go
4
85.92%

Totals

Change from base Build 1017:
-0.2%

Covered Lines:
2045

Relevant Lines:
2249

💛  - Coveralls


Feature fix no colors to run command

I have not identified and fixed the problem with the 3rd-party reporters not working. The problem was that the reporters didn't update the USE_COLORS property, from its default value: false. The feature relies highly on this property to be updated and when it wasn't, the reporter would be interpreted as a no-color reporter.
In-order not to break backwards compatibility, a new property was introduced: EXCLUSIVELY_USE_COLORS with undefined as it's default value. By using this property, the no-colours feature (in the run command) will work for default reporters, i.e. dots and process, and reporters choosing to update the property.
When fixing this, it became obvious why 3rd-party reporters didn't wan't to update this property: They didn't want to implement two reporters, because this would require for their users to add two reporters to their configuration.
For instance; for the mocha reporter, used in #1894, to implement this feature they would first implement two reporters, say reporter:mocha and reporter:mocha_color, which would yield a configuration as:
reporters: ['mocha', 'mocha_color']

where omitting one would disable reporting w/w.o colours, depending on the omitted reporter.
I fixed this in 3294a15 by attempting (silently) to load a "coloured" version of a given reporter. Thus for the mocha reporter to support this feature, all they need to do is implement and export two reporters: reporter:mocha and reporter:mocha_color. The user-configurations would remain unchanged: I.e.
reporters: ['mocha']

Given a reporter with name foo the coloured version must be named foo_color, i.e. with postfix _color.

This looks good but just to be sure can you add a e2e test using the mocha reporter that checks for the correct output please?

@dignifiedquire Yes, I'll add it this weekend.

@budde377 thanks. Do you want to join the karma maintainer team? Main rules are, keep doing great work like you did, and don't push/merge to master on your own.

@dignifiedquire Yes, I would very much like that :)

@budde377 done, welcome to the team

@dignifiedquire Here you go!

@budde377 this needs a rebase after I merged your other PR

@dignifiedquire, Here you go ;)

Thanks. Here goes nothing

Damn. There is another conflict sorry

No prop. This should do the trick.


"Data Transferer" is misspelled

"Transferrer" should have two r's. (It still looks weird, though)

Someone should fix this

Nice... gmod_wire_data_transferer is misspelled. If it's renamed, then dupes that use the old name break.

 :P

We're in [good company] (https://en.wikipedia.org/wiki/HTTP_referer).

hahahaha ok let's keep this misspelling then

From everything I can see, they're both equally acceptable, but transferer is more common. Apparently the rules for whether the final consonant gets doubled depends on whether the final syllable is stressed or not, and the whether people say 'TRANSfer' or 'transFER' seems to be a regional thing, so I'm happy to accept the internet's majority rule here.


Support starting a resumable upload

We should break apart the steps to start and create a resumable upload, supporting use cases like #818.

I added a createURI function to gcs-resumable-upload: https://github.com/stephenplusplus/gcs-resumable-upload#uploadcreateuriconfig-callback
@jgeewax should we still add a method in gcloud-node to call out to that, or just let users use gcs-resumable-upload for that functionality?

@stephenplusplus I see that gcs-resumable-upload is a dependency of gcloud-node. After initializing gcloud, how do I call createURI without requiring gcs-resumable-upload separately?

That's what I was wondering if we should support, and based on you asking, I think it's fair to say we should! As of now, a release with gcs-resumable-upload hasn't been made, so I will try to get that in before we get out 0.21.0. For now, you can use the module directly to get the uri.

Added in #852 - @winduptoy feel free to pull down my branch and give it a shot. Feedback is very welcome!
$ npm install --save stephenplusplus/gcloud-node#spp--storage-allow-starting-resumable-uploads


make joining of server url with API endpoint path a bit smarter

fixes #373

These changes somehow slipped into 073a539


Added metadata to EVC schema

Closes #222
-Modified test

Thanks for the PR, @Alopalao! The changes are very simple and effective! I believe we will need to increase the MEF-Eline API version due to the schema change, v2 -> v3. I would suggest we wait to hear @viniarck opinion on this.
Also, please update the CHANGELOG.

The change itself looks good to me (I'll wait for the changelog that Italo mentioned before approving)
Regarding bumping the API version, let's keep it v2 since it's not breaking compatibility and currently this isn't being used in production yet. So, that simplifies for our team code effort/maintenance wise. Once the API is being used in production or if it's breaking compatibility then we can start bumping the version.
Thanks, guys.


Can't get media No applicable tweets found.

No applicable tweets found.Image : on  /  GIF : on  /  Video : on  /  No media : off  /  include RTs : off
Search filters: filter:images OR card_name:animated_gif OR filter:native_video

[Complete]  -   ( Tweet: 0 / Media: 0 )

You are providing no useful debug information here...


[Snyk] Upgrade com.fasterxml.jackson.core:jackson-core from 2.15.2 to 2.15.3

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade com.fasterxml.jackson.core:jackson-core from 2.15.2 to 2.15.3.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 24 days ago, on 2023-10-12.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Fixed in PR https://github.com/swedenconnect/opensaml-swedish-eid/pull/32


Remote submit

Hi,
I am trying to submit my Formik form from a Header component which is nested 2 levels up. How can I pull that off?
Vague project structure:
Route -> Layout-> Header & Component -> index -> Form

Can you please elaborate a little bit more ? What do you mean by How can I pull that off?


MessageId#compare is not symmetric (MessageIdImpl, BatchMessageIdImpl)

Describe the bug
Given to MessageIds, of which one happens to be a MessageIdImpl and the other is a BatchMessageIdImpl, the compare method is not symmetric.
To Reproduce
import static org.assertj.core.api.Assertions.assertThat;
@Test
public void shouldBeSymmetric() {

    MessageIdImpl simpleMessageId = new MessageIdImpl(1, 2, 3);
    BatchMessageIdImpl batchMessageId = new BatchMessageIdImpl(1, 2, 3, 0);
    assertThat(simpleMessageId.compareTo(batchMessageId)).isEqualTo(batchMessageId.compareTo(simpleMessageId));

    }

Expected behavior
MessageId#compare should be symmetric
Additional context
Pulsar 2.5.0

Thanks @racorn for the reporting. Would you like to provide a fix for this issue?

Yes, I could, but I am not sure how MessageIdImpl and BatchMessageIdImpl should compare?
It seems to me that the asymmetry was introduced by purpose with #1285, the code reads as
} else if (o instanceof MessageIdImpl) {
    int res = super.compareTo(o);
    if (res == 0 && batchIndex > NO_BATCH) {
        return 1;
    } else {
        return res;
    }
}

But as it is now, it breaks the Comparable contract, and that makes it confusing for user of the client API.

I'm interesting in fix this issue.

@zhanghaou Thanks, look forwards to your PR.

Closed as fixed.
Also, the original issue is incorrect because switching the operator of a corporation is never symmetric. The invariant here is:
a.compareTo(b) + b.compareTo(a) == 0;

@tisonkun It is correct that in general compareTo is not symmetric, but a.compareTo(b) == 0 implies that b.compareTo(a) should be 0 as well.
Javadoc for Comparable.compareTo states
The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x))for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)
If I remember correctly, that requirement was not fulfilled for the test data in the original description.

@racorn Anyway, the compare logic for both classes is correct now :)
Some code quality improvements can be made, and you're welcome to give it a review or suggest a test case to cover this issue. See https://github.com/apache/pulsar/pull/18843.


Incorrect error message on voluntary exit command failure

Description
It is common for the voluntary exit command to show an incorrect error message on failure when the error is related to not being able to connect to a URL.
The error message returned is the following:
Failed to connect to beacon node. Check that http://<IP_ADDRESS>:5051 is available.

Reproduce
In the following cases, the error message on failure is the same as above. This is not expected for these cases.

Fail to load validators-external-signer-public-keys from URL
Fail to load keys from URL when validators-external-signer-url is unreachable and the validators-external-signer-public-keys option has been used with external-signer.

Other scenarios would have to be fully investigated to identify the issue.
Found in testing for #8289

fairly happy with error messages now that i've proven the behaviour in testing.


Modify menu ‚All stories‘

Hello, Is there a way to easily exclude one blog category from the ‚ All Stories‘ view? I would like that the articles in one category do not show up on the blog page but only by clicking on the category itself. Thanks for your help.

Hi,
Hmm what "All stories" view do you mean? This theme doesn't have a view like that 🤔

I will close this issue for now, please feel free to reopen it if needed.


Typo in kubectl-plugin - secrete not secret

Typo in kubectl-plugin - has secrete not secret.

Closed by #2644


Adding ressources for Kubernetes and AWS

I have added some articles that I think are useful, I hope it helps.

Hi giqui, thanks for adding those TopCloudOps articles to the list. Likewise, I appreciate the changes on mardkown since I've not been using a markdown lint (which I do at work). Will review if the rendering works as expected (i.e. ToC/Table of Contents).


Update bundle, cloudwatch, sdk-core, ses, sns, ... to 2.27.17

About this PR
📦 Updates

software.amazon.awssdk:bundle
software.amazon.awssdk:cloudwatch
software.amazon.awssdk:sdk-core
software.amazon.awssdk:ses
software.amazon.awssdk:sns
software.amazon.awssdk:sqs
software.amazon.awssdk:ssm

from 2.27.15 to 2.27.17
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #3317.


.git folder listed in "List all pages"

I'm running the wiki on Windows 10, with Python 3.11.2 (venv) and a remote repo set up.
When I list all the pages also the files inside the .git folder are listed.

is the .git folder in the "hide_folder_in_wiki" setting? Also i don't know how hidden files are handled in windows unfortunately

Yes, the settings are like this:
hide_folder_in_wiki: [".obsidian", ".git"]

@Linbreux I should have fixed the problem on Win.
Please, try my fork and tell me if it works also on Linux, then I'll do a PR.

@Linbreux I should have fixed the problem on Win.
Please, try my fork and tell me if it works also on Linux, then I'll do a PR.

Could you create a MR? That's easier to review :)


deepin.deepin-icon-theme: 2023.04.03 -> 2023.11.28

Description of changes
https://github.com/linuxdeepin/deepin-icon-theme/compare/2023.04.03...2023.11.28

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 272859 run on aarch64-linux 1

2 packages built:

deepin.deepin-desktop-theme
deepin.deepin-icon-theme


rounded icon for pwa

@nanot1m feel free to merge this whenever you PR is ready

What about completely round?

That's old school

Can you add it here as well: https://github.com/excalidraw/excalidraw-logo
(and maybe some missing ones)


Tabs on install page unclear

A user on gitter found the installation instructions confusing, thinking that the "Download the binary" tab was the download link itself, styled as a button. We might want to change the styling (so that these boxes look more like tabs than buttons), or the text (this user suggested "Install the binary" instead of "Download the binary", although I'm not sure about this - installing a binary is a step in the build from source instructions, too). The "CockroachDB tarball for [OS]" link could also perhaps be made more prominent (more button-like?)

We've found similar complains during user research. Here're a few low-cost improvement ideas:
If we keep the Mac/Linux/Windows selector:
Option A: Tabs

Option B: Segmented control

Alternatively, we can combine the OS selector (it's defaulted anyways) with the install tabs into something like this to shorten the length of scroll on this page.

What do you think, @bdarnell @jseldess?

Thanks, @kuanluo! I think i like option 2 best, but it'd be great to get more opinions.
Another option would be to not have the second level "buttons/tabs", but rather to use a table of contents, like we have on most other pages, listing the install options. That would leave us just one filter level for OS.

I'm into Option A as it has the best use of hierarchy and organization for the content than the other two options. As a note, the guide could use more direction to reduce some of the cognitive load of scanning around for the important details like install links. Here's a quick example ->

Do our analytics data tell us how often people switch the operating system to a page other than the default? As long as that is rarely used, I like the last option (2? C?).
If we need to keep the OS selection very visible, I prefer option A. The subtly rounded corners of B don't do enough to make it look non-buttony.

I think we do have analytics on how often people change the OS. I'll look today.
Reflecting more on this, I kind of like @josueeee's idea to frame it all as a sequence of steps. The concern about these appearing as buttons has only come up a few times, and the page is used very often, so I wonder if we're overengineering. I'll throw together a quick version of what the page would look like for real with steps and paste a screenshot here this morning.

Good points, @bdarnell @josueeee! Let's take a look at the metrics first and go from there. Thank you, @jseldess for looking into it.

Here are the metrics:

Event Action is the OS button clicked, and Operating System is the OS the user is on. Basically, it confirms that people are clicking on "OS" buttons different than the OS they are on. It makes sense to me that some people do this sometimes (when on Mac or Windows, you might be interested in details about install on Linux, especially if you're SSHing into a Linux server or something). These metrics also probably capture people clicking back and forth (thus the clicks on the Windows button by users already on Windows, etc.).
Unfortunately, we can't know if users are clicking so much because they think these are actual buttons that will do something (the original issue). So not sure what to do with the data. @bdarnell, what are you thoughts?

Actually, the metrics above include the OS buttons on this page as well: https://www.cockroachlabs.com/docs/recommended-production-settings.html#increase-the-file-descriptors-limit
The real numbers, just for the install page, are as follows:

Thanks for the data, @jseldess! One way to go about it is to implement Option A for both the OS as well as the download selector, and see how it affects analytics.

I'll just throw in my two cents.  I like last option, for a few reasons:

I don't think the purpose of this page is to advertise the platform support, so using that much real estate for OS logos seems like a waste.  It's much more important to advertise different ways of installing, since that's the real purpose of this page.
I think it makes it clearer that both questions need to be answered before looking at the content.  The hierarchy isn't all that important here: if you care that it's hierarchical, you'll notice when you switch platforms that the install options change.
I think tabs are confusing when they're in the middle of a page.  I think nested tabs are even more confusing.

@couchand Just to clarify, you prefer Option C in the first batch of mocks? And I agree the nested tabs aren't ideal.
Given that the "disguised tab as button" issue is relatively small (1 github issue and 2 users during interviews), I'd err on the side of making smaller cosmetic updates to begin with/test, and see where it gets us.
Should we start by change download method buttons for tabs only and measure?

@kuanluo yep Option C, my apologies, I can understand the confusion vs. the most recent mockup you posted.  I guess then the segmented control in Option B is a smaller change, but I'm not sure it really addresses the initial concern.  From where I'm sitting the issue is that it's not clear this is a page of instructions, and saving the screen real estate to make as many instructions as possible show up helps clarify that, and putting the OS and install types closer together would also assist.
Or maybe I'm just a tab hater.

Ha, you might be, @couchand. ;) But that's totally allowed.
From the researches we've done as well as anecdotally from our users, our install process is incredibly easy, which makes me hesitant to mess with what is working well. To properly introduce positive changes to the install page, it would take more resources on both design/engineering side. For a quick fix to address the original issue, I'm leaning towards Option A to swap only the download option buttons for tabs as the first step.
We will watch the analytics results in a few weeks, but @couchand, if you volunteer to be the engineering partner on this, we can get results back much quicker. ;)
@jseldess, @bdarnell, what do you think?

I'm good with that, @kuanluo. I agree with @couchand that two levels of tabs feels strange. But I agree with you that, though the page isn't represented as a series of steps, like most of our other tasks/tutorials, it's proved to work very well until now, with some confusion over whether the filters are buttons here and there - the central issue. So let's see if removing that confusion, at least at the second level, makes a difference.

I'm assigning this to DivOf. 👌

Fixed by https://github.com/cockroachdb/docs/pull/1711


⚠ Bofrost.be has degraded performance

In 992f499, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2445 ms

Resolved: Bofrost.be performance has improved in 4c312cc.


Single project page

The client shall include a dedicated page to show all information related to a single/specific fractal project.
The project page shall enable the user to

[ ] #39
[ ] #40
[ ] #41
[ ] #42

One more point I previously forgot to mention:

[ ] Create a new dataset associated to the current project in context


Collect/provide whatsnew entries for v2.3.0 changenotes

( just a task placeholder : TODO=will also need 'showcase features' writing )

Closed by #3442


[server redirection] missing documentation and how to proceed

I´m trying to get an idea of which preconditions are required for handling the [MS-RDPBCGR] <IP_ADDRESS> Server Redirection Packet (RDP_SERVER_REDIRECTION_PACKET)
To be specific, the documentation of the REDIRECTION_VERSION6 (or all other versions for that matter) in <IP_ADDRESS>.5 Client Cluster Data (TS_UD_CS_CLUSTER) is mostly missing.
The versions are mentioned in the spec, but never explained. Only thing that is explained is the windows client version that announces which redirection version. (or is that meant to be the protocol version?)
By experimenting a bit with FreeRDP I already figured out that:

you need to set REDIRECTED_SESSIONID_FIELD_VALID in TS_UD_CS_CLUSTER::Flags to at least get a proper response from a windows RDP server if the REDIRECTION_VERSION is REDIRECTION_VERSION1, REDIRECTION_VERSION2 and REDIRECTION_VERSION6
Failing to do so will result in invalid data sent from the server (short packet)

there is no such requirement for REDIRECTION_VERSION3, REDIRECTION_VERSION4 and REDIRECTION_VERSION5
(not setting REDIRECTED_SESSIONID_FIELD_VALID results in working redirection)

Setting RedirectedSessionID field to an arbitrary value results in the server disconnecting with RPC_INITIATED_DISCONNECT [0x00010001] for all versions

All these tests have been done using a broker setup with windows server 2019 1809 machines.

@pnowack @jotolo2 you might be interested in this, written to dochelp for clarification.

@akallabeth On the client side makes sense that the client sets initially REDIRECTION_SUPPORTED  on <IP_ADDRESS>.5 Client Cluster Data (TS_UD_CS_CLUSTER) and set a REDIRECTION_VERSION compatible with the server.
If REDIRECTION_SUPPORTED is not set, I assume the server shouldn't send any Server Redirection PDU.
From the documentation, I can interpret that this version field defines the Microsoft Windows version the client is running on.
REDIRECTION_VERSION1 and REDIRECTION_VERSION2 are not advertised by any Microsoft RDP clients so I think the server is falling back to interpret these values to a default value that might be REDIRECTION_VERSION6. Testing with a mstsc from Windows 10 I could check that it always sends  REDIRECTION_VERSION6. I'm not sure if there is a different Redirection approach using older versions.
When the client reconnects after having received a [MS-RDPBCGR] <IP_ADDRESS> Server Redirection Packet (RDP_SERVER_REDIRECTION_PACKET) (this PDU provides the RedirectedSessionId), then  REDIRECTED_SESSIONID_FIELD_VALID should be set with the RedirectedSessionId previously received. So it makes sense that sending an arbitrary RedirectedSessionId makes the server disconnect.
It would be great if I could setup two windows systems to test the Redirection on windows.
Please, could you provide me some documentation to see how to do it?

@jotolo2 did not get anything meaningful from dochelp (and did not have time to send them a session dump)
the thing is, if you take the current master code from freerdp and change the FreeRDP_ClusterInfoFlags from REDIRECTION_SUPPORTED | (REDIRECTION_VERSION5 << 2))  to REDIRECTION_SUPPORTED | (REDIRECTION_VERSION6 << 2)) then I can not get any redirection at all as the connection aborts early for some reason.

@jotolo2 the stuff with the REDIRECTED_SESSIONID_FIELD_VALID was just me going through all posible values to send initially

@jotolo2 I get:
[17:12:32:452] [162779:162895] [INFO][com.winpr.timezone] - [winpr_detect_windows_time_zone]: tzid: Europe/Vienna
[17:12:32:483] [162779:162895] [INFO][com.freerdp.core.license] - [license_client_recv]: Receiving ERROR_ALERT Packet
[17:12:32:483] [162779:162895] [WARN][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type BB_ERROR_BLOB, length=0, skipping.
[17:12:32:531] [162779:162895] [WARN][com.freerdp.core.rdp] - [Stream_CheckAndLogRequiredLengthWLogExVa]: [rdp_read_share_control_header(/home/nin/src/freerdp/libfreerdp/core/rdp.c:216)] invalid length, got 8, require at least 4094 [element size=1]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 0: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/client/X11/xfreerdp(backtrace+0x5b) [0x45ea0b]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 1: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(winpr_execinfo_backtrace+0xc2) [0x7ffff6391c82]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 2: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(winpr_backtrace+0x13) [0x7ffff638dd43]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 3: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(winpr_log_backtrace_ex+0xb6) [0x7ffff638df96]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 4: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(Stream_CheckAndLogRequiredLengthWLogExVa+0x25e) [0x7ffff638cebe]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 5: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(Stream_CheckAndLogRequiredLengthExVa+0x10c) [0x7ffff638cc3c]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 6: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(Stream_CheckAndLogRequiredLengthEx+0x20f) [0x7ffff638caaf]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 7: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_read_share_control_header+0x668) [0x7ffff6a1b168]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 8: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_recv_demand_active+0x453) [0x7ffff69cca83]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 9: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_client_connect_demand_active+0x2f0) [0x7ffff69fbf50]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 10: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(+0x4281af) [0x7ffff6a281af]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 11: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_recv_callback+0x217) [0x7ffff6a26fd7]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 12: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(transport_check_fds+0x5b1) [0x7ffff6a4d591]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 13: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_check_fds+0x1b0) [0x7ffff6a28c80]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 14: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(+0x3f6faa) [0x7ffff69f6faa]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 15: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_client_connect+0x1104) [0x7ffff69f6444]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 16: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(+0x39fa86) [0x7ffff699fa86]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 17: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(freerdp_connect+0x102) [0x7ffff699e4d2]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 18: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/client/X11/xfreerdp() [0x5486ee]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 19: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(+0x1fb2e6) [0x7ffff63fb2e6]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [Stream_CheckAndLogRequiredLengthWLogExVa]: [rdp_read_share_control_header(/home/nin/src/freerdp/libfreerdp/core/rdp.c:216)] invalid length, got 8, require at least 4094 [element size=1]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 0: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/client/X11/xfreerdp(backtrace+0x5b) [0x45ea0b]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 1: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(winpr_execinfo_backtrace+0xc2) [0x7ffff6391c82]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 2: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(winpr_backtrace+0x13) [0x7ffff638dd43]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 3: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(winpr_log_backtrace_ex+0xb6) [0x7ffff638df96]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 4: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(Stream_CheckAndLogRequiredLengthWLogExVa+0x25e) [0x7ffff638cebe]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 5: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(Stream_CheckAndLogRequiredLengthExVa+0x10c) [0x7ffff638cc3c]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 6: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(Stream_CheckAndLogRequiredLengthEx+0x20f) [0x7ffff638caaf]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 7: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_read_share_control_header+0x668) [0x7ffff6a1b168]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 8: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_recv_out_of_sequence_pdu+0xe4) [0x7ffff6a25754]
[17:12:32:554] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 9: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_client_connect_demand_active+0x347) [0x7ffff69fbfa7]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 10: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(+0x4281af) [0x7ffff6a281af]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 11: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_recv_callback+0x217) [0x7ffff6a26fd7]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 12: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(transport_check_fds+0x5b1) [0x7ffff6a4d591]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 13: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_check_fds+0x1b0) [0x7ffff6a28c80]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 14: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(+0x3f6faa) [0x7ffff69f6faa]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 15: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(rdp_client_connect+0x1104) [0x7ffff69f6444]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 16: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(+0x39fa86) [0x7ffff699fa86]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 17: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/libfreerdp/libfreerdp3.so.3(freerdp_connect+0x102) [0x7ffff699e4d2]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 18: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/client/X11/xfreerdp() [0x5486ee]
[17:12:32:555] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 19: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/winpr/libwinpr/libwinpr3.so.3(+0x1fb2e6) [0x7ffff63fb2e6]
[17:12:32:555] [162779:162895] [ERROR][com.freerdp.core.rdp] - [rdp_recv_callback_int]: CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE status STATE_RUN_FAILED [-1]
[17:12:32:555] [162779:162895] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
[17:12:32:555] [162779:162895] [ERROR][com.freerdp.core] - [freerdp_set_last_error_ex]: rdp_client_wait_for_activation ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]

If this happens on a reconnection and the client isn't sending also RedirectedSessionId that would make sense.
But if this happens just on the initial connection, only REDIRECTION_SUPPORTED | (REDIRECTION_VERSION6 << 2)) should be enough.
Maybe this is happening because the server is running an old RDP version which only supports until REDIRECTION_VERSION5. Or maybe we are missing something...

@jotolo2 it happens on the initial connection. server is a broker setup with server 2019, so should be recent enough...
anyway, if that version just represents the client os version then that behavior is very strange as newer clients would never work with older servers ...

@jotolo2 I´ve dumped the traffic between client and server and it is indeed the initial connection.
I´ve added some debug log and Instead of
[INFO][com.freerdp.core.rdp] - [rdp_recv_callback]: received 296 bytes, state CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE (that is the redirection PDU) I get
[INFO][com.freerdp.core.rdp] - [rdp_recv_callback]: received 24 bytes, state CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE
The dump for REDIRECTION_VERSION6 is

[winpr_HexLogDump]: 0000 03 00 00 18 02 f0 80 68 00 01 03 f0 70 0a 00 10 .......h....p...
[winpr_HexLogDump]: 0016 00 00 06 00 00 00 14 00                         ........
[winpr_HexLogDump]: [length=24]

whereas if I send REDIRECTION_VERSION5

[winpr_HexLogDump]: 0000 03 00 01 28 02 f0 80 68 00 01 03 eb 70 81 19 19 ...(...h....p...
[winpr_HexLogDump]: 0016 01 0a 00 ea 03 25 96 00 04 10 01 16 00 00 00 0d .....%..........
[winpr_HexLogDump]: 0032 3b 00 00 1e 00 00 00 31 00 39 00 32 00 2e 00 31 ;......1.9.2...1
[winpr_HexLogDump]: 0048 00 36 00 38 00 2e 00 35 00 30 00 2e 00 32 00 33 .6.8...5.0...2.3
[winpr_HexLogDump]: 0064 00 32 00 00 00 0c 00 00 00 64 00 65 00 6d 00 6f .2.......d.e.m.o
[winpr_HexLogDump]: 0080 00 31 00 00 00 0e 00 00 00 52 00 44 00 54 00 45 .1.......R.D.T.E
[winpr_HexLogDump]: 0096 00 53 00 54 00 00 00 22 00 00 00 52 00 44 00 32 .S.T..."...R.D.2
[winpr_HexLogDump]: 0112 00 2e 00 72 00 64 00 74 00 65 00 73 00 74 00 2e ...r.d.t.e.s.t..
[winpr_HexLogDump]: 0128 00 6c 00 6f 00 63 00 61 00 6c 00 00 00 08 00 00 .l.o.c.a.l......
[winpr_HexLogDump]: 0144 00 52 00 44 00 32 00 00 00 58 00 00 00 74 00 73 .R.D.2...X...t.s
[winpr_HexLogDump]: 0160 00 76 00 3a 00 2f 00 2f 00 4d 00 53 00 20 00 54 .v.:././.M.S. .T
[winpr_HexLogDump]: 0176 00 65 00 72 00 6d 00 69 00 6e 00 61 00 6c 00 20 .e.r.m.i.n.a.l.
[winpr_HexLogDump]: 0192 00 53 00 65 00 72 00 76 00 69 00 63 00 65 00 73 .S.e.r.v.i.c.e.s
[winpr_HexLogDump]: 0208 00 20 00 50 00 6c 00 75 00 67 00 69 00 6e 00 2e . .P.l.u.g.i.n..
[winpr_HexLogDump]: 0224 00 31 00 2e 00 44 00 65 00 73 00 6b 00 74 00 6f .1...D.e.s.k.t.o
[winpr_HexLogDump]: 0240 00 70 00 00 00 26 00 00 00 01 00 00 00 1e 00 00 .p...&..........
[winpr_HexLogDump]: 0256 00 31 00 39 00 32 00 2e 00 31 00 36 00 38 00 2e .1.9.2...1.6.8..
[winpr_HexLogDump]: 0272 00 35 00 30 00 2e 00 32 00 33 00 32 00 00 00 00 .5.0...2.3.2....
[winpr_HexLogDump]: 0288 00 00 00 00 00 00 00 20                         .......
[winpr_HexLogDump]: [length=296]

That is what the server answers after the client sends the [MS-RDPBCGR]  <IP_ADDRESS> Client MCS Connect Initial PDU.
Is it a [MS-RDPBCGR]  <IP_ADDRESS> Server MCS Connect Response PDU?
It doesn't look like a Server Redirection PDU.
I can see the TPKT header and the X.224 Class 0 Data TPDU, but after that, I'm not sure what is 68 00 01 03.

Wait... from what I see on the documentation now:

The version values cannot be combined; only one value MUST be specified if the REDIRECTED_SESSIONID_FIELD_VALID (0x00000002) flag is present in the Flags field.

It looks like the REDIRECTION_VERSION<X> should only be set when the client reconnects and it actually has a RedirectedSessionId obtained from the [MS-RDPBCGR] <IP_ADDRESS> Server Redirection Packet.

@jotolo2 ok, I think you´re onto something here :)
testing this...

@jotolo2 ok, if I only send REDIRECTION_SUPPORTED on initial connection then I have the same/similar error. Only the packet size is different:
[winpr_HexLogDump]: 0000 03 00 00 36 02 f0 80 68 00 01 03 eb 70 28 00 01 ...6...h....p(..
[winpr_HexLogDump]: 0016 28 00 16 00 00 00 31 00 39 00 32 00 2e 00 31 00 (.....1.9.2...1.
[winpr_HexLogDump]: 0032 36 00 38 00 2e 00 35 00 30 00 2e 00 32 00 33 00 6.8...5.0...2.3.
[winpr_HexLogDump]: 0048 32 00 00 00 82 78                               2....x
[winpr_HexLogDump]: [length=54]

That's a [MS-RDPBCGR]  <IP_ADDRESS> Server MCS Connect Response PDU but with less data than what was expected?
I think I would test the redirection with mstsc and use wireshark to see what differs from FreeRDP.
Is it too hard to set up a Windows RDP server to test redirection?

@jotolo2 it is hard to set up the whole thing with legacy RDP encryption which is breakable otherwise wireshark is not very useful ;)
Anyway, the documentation is lying, for REDIRECTION_SUPPORTED it tells
The client can receive server session redirection packets. If this flag is set, the ServerSessionRedirectionVersionMask MUST contain the server session redirection version that the client supports.

but if that is REDIRECTION_VERSION6 the server just responds with garbage :/
The thing you mentioned in the spec comes later, when we have a session to resume and we set the REDIRECTED_SESSIONID_FIELD_VALID flag

@jotolo2 just for consistency sake, also tried to send no flag at all, then the session terminates proplerly as redirection is not supported.

Hello @akallabeth.
I think I've found out the cause of the error you shared:
[17:12:32:452] [162779:162895] [INFO][com.winpr.timezone] - [winpr_detect_windows_time_zone]: tzid: Europe/Vienna
[17:12:32:483] [162779:162895] [INFO][com.freerdp.core.license] - [license_client_recv]: Receiving ERROR_ALERT Packet
[17:12:32:483] [162779:162895] [WARN][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type BB_ERROR_BLOB, length=0, skipping.
[17:12:32:531] [162779:162895] [WARN][com.freerdp.core.rdp] - [Stream_CheckAndLogRequiredLengthWLogExVa]: [rdp_read_share_control_header(/home/nin/src/freerdp/libfreerdp/core/rdp.c:216)] invalid length, got 8, require at least 4094 [element size=1]
[17:12:32:553] [162779:162895] [WARN][com.freerdp.core.rdp] - [winpr_log_backtrace_ex]: 0: /home/nin/src/build-freerdp-Qt_in_PATH_System-Debug/client/X11/xfreerdp(backtrace+0x5b) [0x45ea0b]

It looks like when setting REDIRECTION_VERSION6, the server will send a [MS-RDPBCGR] <IP_ADDRESS> Server Initiate Multitransport Request PDU even if the client didn't provide support for Multitransport on block <IP_ADDRESS>.8 Client Multitransport Channel Data (TS_UD_CS_MULTITRANSPORT) from GCC Conference Create Request.
So the error occurs when the client is expecting a <IP_ADDRESS>.1 Server Demand Active PDU but is receiving a <IP_ADDRESS> Server Initiate Multitransport Request PDU instead.
This won't happen if the client is configured to support multitransport. I've set /multitransport option with xfreerdp and didn't get the error.
What's your opinion about supporting on the client multitransport by default? It looks like mstsc already does. And if we want to use REDIRECTION_VERSION6 it should be a requirement.
I still don't know why the server needs multitransport and what is its purpose in the redirection process...

@jotolo2 oh, interesting find. enabling multitransport by default is indeed a good idea, as future support for UDP will require it anyway.


[Annotations] Add multidimensional array support

Description:
Add multidimensional array support for annotations. An example is as follows.
annotation configs {
    string[][] valueSets;
}

@configs {
    valueSets:[["val1", "val2"], ["val3", "val4"]]
}

Affected Versions:
0.960

This will get sorted by issue #4887.


Travis-CI?

Setup a Travis for nightly builds would be cool :D

I don't know, but I think it would be cool to just click a button and have a build ready, which includes every change you have done a minute ago...

Well, if you want to do this, you have to do it, because only the admin can configure his repos ^^

Closed for now... Maybe we do this later on... But I think we let that closed


Simple service server: no response is sent

Hi! I am trying to create an "add_two_ints" service server, based on the example from micro-ROS-demos repo here, but modified to get the " void_setup() / void_loop() format ". The server receives the request, but no response is sent to the service client.
Setup:

Computer: ROS2 Foxy / Ubuntu 20.04
Board: Teensy 3.1 / Arduino IDE 1.8.13 / Teensyduino 1.53
Board is connected to computer via USB cable.

Steps to reproduce:
The .ino source code uploaded on the Teensy is:
#include <micro_ros_arduino.h>
#include <example_interfaces/srv/add_two_ints.h>
#include <stdio.h>
#include <rcl/error_handling.h>
#include <rclc/rclc.h>
#include <rclc/executor.h>
#include <std_msgs/msg/int64.h>

// ros:
rcl_init_options_t options;
rcl_node_options_t node_ops;
rcl_node_t node;
rclc_support_t support;
rcl_allocator_t allocator;
rclc_executor_t executor;

// service:
rcl_service_options_t service_options;
rcl_service_t serv;
const rosidl_service_type_support_t * service_type_support;
rcl_wait_set_t wait_set;

// **** SETUP ****
void setup() {
 delay(5000);
 allocator = rcl_get_default_allocator();

 options = rcl_get_zero_initialized_init_options();
 rcl_init_options_init(&options, rcl_get_default_allocator());

 rclc_support_init(&support, 0, NULL, &allocator);

 node_ops = rcl_node_get_default_options();
 node = rcl_get_zero_initialized_node();
 rclc_node_init_default(&node, "micro_ros_service_server_node", "", &support);

 // init server
 const char * service_name = "/add_two_ints";
 service_options = rcl_service_get_default_options();
 serv = rcl_get_zero_initialized_service();
 service_type_support = ROSIDL_GET_SRV_TYPE_SUPPORT(example_interfaces, srv, AddTwoInts);
 rcl_service_init(&serv, &node, service_type_support, service_name, &service_options);
 wait_set = rcl_get_zero_initialized_wait_set();
 rcl_wait_set_init(&wait_set, 0, 0, 0, 1, 0, 0, &support.context, rcl_get_default_allocator());

 executor = rclc_executor_get_zero_initialized_executor();
 rclc_executor_init(&executor, &support.context, 1, &allocator);
}

//**** LOOP ****
void loop() {
 delay(100);
 rcl_wait_set_clear(&wait_set);

 size_t index;
 rcl_wait_set_add_service(&wait_set, &serv, &index);

 rcl_wait(&wait_set, RCL_MS_TO_NS(1));
 for (size_t i = 0; i < wait_set.size_of_services; i++) {
   if (wait_set.services[i]) {

     rmw_request_id_t req_id;

     example_interfaces__srv__AddTwoInts_Request req;
     example_interfaces__srv__AddTwoInts_Request__init(&req);

     rcl_take_request(&serv, &req_id, &req);

     example_interfaces__srv__AddTwoInts_Response res;
     example_interfaces__srv__AddTwoInts_Response__init(&res);

     res.sum = req.a + req.b;

     rcl_send_response(&serv, &req_id, &res);
   }
 }
 rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100));
}

Once the micro-ROS agent is running, I got the output:
[1604311603.418290] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1604311603.918485] info     | TermiosAgentLinux.cpp | fini                     | server stopped         | fd: 3
[1604311603.918687] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3

[1604311607.854237] info     | Root.cpp           | create_client            | create                 | client_key: 0x01A06D5E, session_id: 0x81
[1604311607.854339] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x27290974, address: 1
[1604311607.854525] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 19, data:
0000: 81 00 00 00 04 01 0B 00 00 00 58 52 43 45 01 00 01 0F 00
[1604311607.857389] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 116, data:
0000: 81 80 00 00 01 05 6C 00 00 0A 00 01 01 02 00 00 5E 00 00 00 3C 64 64 73 3E 3C 70 61 72 74 69 63
0020: 69 70 61 6E 74 3E 3C 72 74 70 73 3E 3C 6E 61 6D 65 3E 6D 69 63 72 6F 5F 72 6F 73 5F 73 65 72 76
0040: 69 63 65 5F 73 65 72 76 65 72 5F 6E 6F 64 65 3C 2F 6E 61 6D 65 3E 3C 2F 72 74 70 73 3E 3C 2F 70
0060: 61 72 74 69 63 69 70 61 6E 74 3E 3C 2F 64 64 73 3E 00 00 00
[1604311607.863867] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80
[1604311607.865046] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80
[1604311607.865900] debug    | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x01A06D5E, participant_id: 0x000(1)
[1604311607.865946] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 14, data:
0000: 81 80 00 00 05 01 06 00 00 0A 00 01 00 00
[1604311607.865958] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1604311607.865965] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1604311607.865972] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1604311607.867175] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80
[1604311607.867186] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1604311607.867264] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1604311607.879828] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 352, data:
0000: 81 80 01 00 01 05 58 01 00 0B 00 08 08 02 00 00 4A 01 00 00 3C 64 64 73 3E 3C 72 65 70 6C 69 65
0020: 72 20 70 72 6F 66 69 6C 65 5F 6E 61 6D 65 3D 22 30 5F 38 22 20 73 65 72 76 69 63 65 5F 6E 61 6D
0040: 65 3D 22 2F 61 64 64 5F 74 77 6F 5F 69 6E 74 73 22 20 72 65 71 75 65 73 74 5F 74 79 70 65 3D 22
0060: 65 78 61 6D 70 6C 65 5F 69 6E 74 65 72 66 61 63 65 73 3A 3A 73 72 76 3A 3A 64 64 73 5F 3A 3A 41
0080: 64 64 54 77 6F 49 6E 74 73 5F 52 65 71 75 65 73 74 5F 22 20 72 65 70 6C 79 5F 74 79 70 65 3D 22
00A0: 65 78 61 6D 70 6C 65 5F 69 6E 74 65 72 66 61 63 65 73 3A 3A 73 72 76 3A 3A 64 64 73 5F 3A 3A 41
00C0: 64 64 54 77 6F 49 6E 74 73 5F 52 65 73 70 6F 6E 73 65 5F 22 3E 3C 72 65 71 75 65 73 74 5F 74 6F
00E0: 70 69 63 5F 6E 61 6D 65 3E 72 71 2F 61 64 64 5F 74 77 6F 5F 69 6E 74 73 52 65 71 75 65 73 74 3C
0100: 2F 72 65 71 75 65 73 74 5F 74 6F 70 69 63 5F 6E 61 6D 65 3E 3C 72 65 70 6C 79 5F 74 6F 70 69 63
0120: 5F 6E 61 6D 65 3E 72 72 2F 61 64 64 5F 74 77 6F 5F 69 6E 74 73 52 65 70 6C 79 3C 2F 72 65 70 6C
0140: 79 5F 74 6F 70 69 63 5F 6E 61 6D 65 3E 3C 2F 72 65 70 6C 69 65 72 3E 3C 2F 64 64 73 3E 00 00 01
[1604311607.879877] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 01 00 80
[1604311607.879884] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 01 00 80
[1604311607.879892] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 01 00 80
[1604311607.880998] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 01 00 80
[1604311607.881208] debug    | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x01A06D5E, requester_id: 0x000(7), participant_id: 0x000(1)
[1604311607.881269] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 14, data:
0000: 81 80 01 00 05 01 06 00 00 0B 00 08 00 00
[1604311607.881280] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.881287] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.881293] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.881301] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.881307] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.886692] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 01 00 80
[1604311607.886751] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.887799] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1604311607.987966] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 24, data:
0000: 81 80 02 00 08 01 10 00 00 0C 00 08 80 00 00 01 FF FF 00 00 00 00 00 00
[1604311607.988130] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80
[1604311608.087934] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 02 00 80
[1604311608.088091] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80
[1604311608.089162] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 01 00 02 00 80
[1604311608.089334] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80
[1604311608.188686] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 02 00 02 00 80
[1604311608.188825] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80
[1604311608.390812] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0B 01 05 00 02 00 02 00 80
[1604311608.391055] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80

Then I call the service in another shell with the command:
ros2 service call add_two_ints example_interfaces/srv/AddTwoInts "{a: 1, b: 0}"
, which output is:
waiting for service to become available...
requester: making request: example_interfaces.srv.AddTwoInts_Request(a=1, b=0)

The micro-ROS agent response is:
[1604311838.727954] debug    | Replier.cpp        | read_fn                  | [==>> DDS <<==]        | client_key: 0x00000000, len: 40, data:
0000: 01 0F 8E E6 C1 71 01 00 01 00 00 00 00 00 12 03 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00
[1604311838.728068] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x01A06D5E, len: 52, data:
0000: 81 80 02 00 09 01 2C 00 00 0C 00 08 01 0F 8E E6 C1 71 01 00 01 00 00 00 00 00 12 03 00 00 00 00
0020: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[1604311838.745935] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x01A06D5E, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80

So, the service is recognized as available, and the server receives the request, but the response is not sent.
I also tried to launch the micro-ROS agent via a docker:
 sudo docker run -it --rm -v /dev:/dev --privileged --net=host microros/micro-ros-agent:foxy serial --dev /dev/teensy -v6
The outputs are the same.
I guess this issue is due to my .ino source code. Do you have any idea what causes this? Thanks for helping!

Working on it, I'll tell you something asap.

Hello @anaelle-sw I found something:
Please recheck this line.
You have written:
 rcl_wait_set_init(&wait_set, 0, 0, 0, 1, 0, 0, &support.context, rcl_get_default_allocator());

and in the demo it says:
rcl_wait_set_init(&wait_set, 0, 0, 0, 0, 1, 0, &context, rcl_get_default_allocator())

You are not creating a wait set with one service "slot". Check the function here.
Close if you are ok with this answer, I'm going to add to this repo a service example!

Other considerations, services, and clients are not fully supported in the RCLC (the micro-ROS user API), and you have to use the RCL. This is going to be fixed as soon as we can, but by now please take care when mixing both APIs. I suggest that you can remove the  rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) since you are actually doing a rcl_wait() previously.
Of course, you can mix the call to both, but please be aware of this.

You have my working example here

Hi! Thanks for these explanations, especially about the RCLC / RCL libraries. I was not really being careful with using one or the other.
I actually tried to use the function as used in the demo:
rcl_wait_set_init(&wait_set, 0, 0, 0, 0, 1, 0, &context, rcl_get_default_allocator())
This way, the service client did detect the service as available, but the micro-ROS agent wasn't not notifying that any request was received. So I thought I was closer to a solution using &support.context, since the request was received.
Anyway, your example server is working nicely for me, thanks!
Just a quick question before closing this issue please: in your example service server code, you initialize an executor in the void setup() function here, and then in the void_loop() function you use a rcl_wait() here. As you explained, it is not necessary to use rclc_executor_spin_some(). So why you actually need to initialize an executor anyway? Sorry if this question does not belong here, it may be quite related to "general" micro-ROS

Hello @anaelle-sw,
You are right, if in the loop we are using a rcl_waitset directly, the executor is not needed. In fact, as you can see here, the RCLC executor is just a sort of intelligent wrapper for the waitset, internally the executor handles its own waitset and allows the user setting callbacks, managing the execution order and so on...
So basically, we are using here the rcl_waitset because we don't have yet support for services in the executor. As soon as we merge this, you can forget the waitsets and work with the RCLC API and its callbacks.
I hope that this is not a big inconvenient.

Ok, I understand better now.
Actually, I am as new to RCL than to RCLC, so it won't be a big deal in my case.
I will close this issue. Thanks for your time!

Related: Check here the new service/client API in RCLC.

Very nice to have service callbacks directly in the API. This way, it is really lighter and more intuitive to use. Thanks for notifying me about it!

Just three quick questions about this new RCLC API and your example code:
(if you want, I can open a new issue instead of posting here, let me know)

In your example code, you declare a rcl_wait_set_t but don't initialize it, neither use it (as well as a rmw_request_id_t and a rosidl_service_type_support_t by the way). In my case, it works well if these are not declared. If I don't misunderstand, a wait set is not required anymore with the RCLC API, as you have an executor spinning (rclc_executor_spin_some in the loop), and RCLC directly handles this, is this right?

I don't need the res and req outside the service callback. Can I just don't declare these are global variables, and go with

rclc_executor_add_service(
                       &executor,
                       &service,
                       &example_interfaces__srv__AddTwoInts_Request(),
                       &example_interfaces__srv__AddTwoInts_Response(),
                       service_callback);

when initializing my service? My code builds this way, and everything seems to work normally. But can this lead to known problems? (I am thinking about memory leak for instance)

Is there a way to wait for the response to be sent, inside the callback? Actually, I need to copy strings inside res->message. As you told me in this post, I cannot directly copy paste strings, but must use memory allocation and memory copy. For instance, when following this instruction, one of my services' callbacks looks like this:

void trigger_srv_cb(const void * req_in, void * res_in){
  std_srvs__srv__Trigger_Request * req = (std_srvs__srv__Trigger_Request *) req_in;
  std_srvs__srv__Trigger_Response * res = (std_srvs__srv__Trigger_Response *) res_in;

  res->message.data = (char*)malloc(200 * sizeof(char));
  res->message.size = 0;
  res->message.capacity = 200;
  memcpy(res->message.data, "trigger executed", 200);
  res->message.size = strlen(res->message.data);

  free(res->message.data);
}

The problem is I need to execute free after malloc to avoid memory leak.  But with RCLC API (which is really more convenient, and that I am really willing to use) the response might not be sent before executing free. What is the correct way to handle this?

Hello @anaelle-sw just I forgot to merge https://github.com/micro-ROS/micro_ros_arduino/pull/45, so:

solved in https://github.com/micro-ROS/micro_ros_arduino/pull/45

Wow, this is tricky. Where do you have defined example_interfaces__srv__AddTwoInts_Response() I'm not sure if they are pure C99 implementation or  Arduino C++. Usually you have to provide a req and res object to the executor to let it have some memory to save the req and res since the executor is not allowed to alloc memory. In Arduino I usually put all the variables as global since setup() stack variables can't be used in loop()... Does your solution work?

If you follow the example we provide, you have req and res declared as global variables. So I suggest you to do the

example_interfaces__srv__AddTwoInts_Response res;
example_interfaces__srv__AddTwoInts_Request req;

void setup(){
...
  res.message.data = (char*)malloc(200 * sizeof(char));
  res.message.size = 0;
  res.message.capacity = 200;
  RCCHECK(rclc_executor_add_service(&executor, &service, &req, &res, service_callback));
....

in the setup(). Then you provide those two object to the executor and you have guaranteed that in the callback the executor will pass you the couple of pointers that are the same that you provide: so the res is already init and allocated with the malloc. So in the callback you just do:
void trigger_srv_cb(const void * req_in, void * res_in){
  std_srvs__srv__Trigger_Request * req = (std_srvs__srv__Trigger_Request *) req_in;
  std_srvs__srv__Trigger_Response * res = (std_srvs__srv__Trigger_Response *) res_in;

  memcpy(res->message.data, "trigger executed", 200);   <-- be careful with this 200, your string is not 200!
  res->message.size = strlen(res->message.data);
}

Also be SUPER careful with copying not NULL-ending string because serialization for strings relies in a '\0' at the end... Maybe is safer a fprintf(res->message.data, "%s", "blablabla").

Well, I didn't defined example_interfaces__srv__AddTwoInts_Response() actually, just included the file example_interfaces/srv/add_two_ints.h. Yes the code works this way, but I just tested it with your example code for now, with a few service calls.

Ok then, I will follow your advice and just use global variables (I am used to limit the number of global variables when programming ROS nodes for instance, but in the case of Arduino code I guess it is not a problem).

The problem with fprintf(res->message.data, "%s", "blablabla") is that you can only see this debug string via the serial monitor provided by Arduino IDE, is this right? But here we would need to get the res->message in ROS, or at least in a terminal.

 be careful with this 200, your string is not 200!

This could be a quite big problem with our application. We need to regularly copy strings in a message (which is published by our board). The problem is the strings have different length. So having something like this:
memcpy(res->message.data, "trigger executed", sizeof("trigger executed"));
, and later on something like this (on the same res->message):
memcpy(res->message.data, "foo", sizeof("foo"));
, results on publishing a message like this:
"foogger executed".
My solution for this was to set a maximum string length( #define MAX_LEN_STR 100), and use it every time I need to copy a string:
memcpy(res->message.data, "trigger executed", MAX_LEN_STR);.
For now, it works very well with our string-containing message publication, and a ROS node processing the strings. The tests I ran for now lasted around 20min max, no problem related to the published strings occurred. What can happen if the size given in memcpy is not the one of the copied string?

Sorry I didn't write the function well. I didn't mean fprintf I meant sprintf.
You are having the "foogger executed" string because you are not handling the '\0' character for null-ending the string. My solution for copying a string to a buffer is:
sprintf(res->message.data, "%s", "blablabla")
res->message.size = strlen(res->message.data);

This writes "blablabla\0" to your buffer, so strlen will work to obtain the size.

What can happen if the size given in memcpy is not the one of the copied string?

Multiple things:

You are copying unnecessary bytes to a buffer, and at some point, this is inefficient
Imagine that you are telling the code to copy "blabla" to buf[100] with memcpy(buf, "blabla", 100);. You know that buf has 100 slots to write but does the literal "blabla" (which is in the flash .const section) has 100 characters for reading? Imagine your string is stored at the end of the memory, in this case you will do an illegal read. Imagine you are in Linux, probably you will have a segfault if you read from a section of memory that does not belong to your process.
Your string are only NULL-terminated if the buffer is previously set to 0

Ok, I got it now. Thank you very much for all explanations!


package.json should depend on "babel", not "babel-core"

If you try to run any gulp task without having installed babel on your system, you get:
[14:37:50] Failed to load external module babel/register
~/code/foo/gulpfile.babel.js:25
import fs from 'fs';
^^^^^^
SyntaxError: Unexpected reserved word

The package.json includes babel-core, which is not being used AFAICT, so I'm assuming this was supposed to be babel.

See https://github.com/google/web-starter-kit/pull/727, you're likely just on an old gulp version.

Try updating your global gulp:
npm install -g gulp

Oh cool, I didn't know babel-core had /register in it, thanks

So then I guess this issue can be closed?

Thought I did


Update bundler before travis builds

Latest builds on travis are broken because of bundler is too old and contains some issues.
Refs: https://travis-ci.org/rspec/rspec-rails/jobs/273646937 https://github.com/travis-ci/travis-ci/issues/3531

Although the build failed due to other reasons, it was confirmed that the latest bundler version can be used.
[Before]

https://travis-ci.org/rspec/rspec-rails/jobs/273646937#L1032
Bundler version 1.7.6

[After]

https://travis-ci.org/rspec/rspec-rails/jobs/273993737#L741
Bundler version 1.15.4

Seems legit to me, thank you!


Update KubeadmConfigTemplate version and CAPI version

What this PR does / why we need it:
Update KubeadmConfigTemplate version and CAPI version
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #279

e2e
  Timeline >>
  STEP: Tearing down the management cluster @ 06/09/23 05:27:35.819
  << Timeline
------------------------------

Ran 7 of 26 Specs in 3221.786 seconds
SUCCESS! -- 7 Passed | 0 Failed | 0 Pending | 19 Skipped

unit test
?   	github.com/oracle/cluster-api-provider-oci	[no test files]
ok  	github.com/oracle/cluster-api-provider-oci/api/v1beta1	45.363s	coverage: 24.1% of statements
ok  	github.com/oracle/cluster-api-provider-oci/api/v1beta2	0.100s	coverage: 15.8% of statements
?   	github.com/oracle/cluster-api-provider-oci/cloud/config	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/metrics	[no test files]
ok  	github.com/oracle/cluster-api-provider-oci/cloud/ociutil	0.003s	coverage: 19.6% of statements
ok  	github.com/oracle/cluster-api-provider-oci/cloud/scope	240.864s	coverage: 75.5% of statements
?   	github.com/oracle/cluster-api-provider-oci/cloud/scope/mocks	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/base	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/base/mock_base	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/compute	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/compute/mock_compute	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/computemanagement	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/computemanagement/mock_computemanagement	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/containerengine	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/containerengine/mock_containerengine	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/identity	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/identity/mock_identity	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/loadbalancer	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/loadbalancer/mock_lb	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/networkloadbalancer	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/networkloadbalancer/mock_nlb	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/vcn	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/cloud/services/vcn/mock_vcn	[no test files]
ok  	github.com/oracle/cluster-api-provider-oci/cloud/util	0.256s	coverage: 76.1% of statements
ok  	github.com/oracle/cluster-api-provider-oci/controllers	26.039s	coverage: 67.5% of statements
ok  	github.com/oracle/cluster-api-provider-oci/exp/api/v1beta1	29.919s	coverage: 18.7% of statements
ok  	github.com/oracle/cluster-api-provider-oci/exp/api/v1beta2	0.044s	coverage: 9.5% of statements
ok  	github.com/oracle/cluster-api-provider-oci/exp/controllers	1.711s	coverage: 56.7% of statements
?   	github.com/oracle/cluster-api-provider-oci/feature	[no test files]
?   	github.com/oracle/cluster-api-provider-oci/version	[no test files]


Location data missing in database

I had a look at my (digital picture frame in the living room) database with the DB Browser. There are about 1,250 photos in there. All, except for a few exceptions, have GPS coordinates. Yet about 300 of them don't have an identified location.
I was trying to identify a pattern, but couldn't find one. I wonder if anybody else has come across this.

That is strange, assuming they've all been displayed. (To start with no images have location info) Did you notice it from seeing photos on the display with no location?
Is the internet connection reliable for the picframe? If it's intermittent then I would expect the locations to be filled in eventually.

That is strange, assuming they've all been displayed. (To start with no images have location info) Did you notice it from seeing photos on the display with no location?

I will pull these photos over to my Test Pi and see what happens. And yes, the playlist has been circulating for quite some time.

Is the internet connection reliable for the picframe? If it's intermittent then I would expect the locations to be filled in eventually.

Very much so. We have 100 M/bit internet and the router is 4 meters away from the frame. Signal strength is strong.

Ok, so I imported the images on my Test Pi and let it run for a while. All 1250 images were recognized with the location.
Strange.

Is the DB actually deleted when upgrading PictureFrame?

I don't think it is. That certainly wasn't the idea.

Ok, good to know. Just trying to understand the root cause of the issue.

Is there anything left to do?

@sapnho Can we close this?

Yes.


Input change event

Hi, please tell me to put the event on the change field for input, but it works only if the focus is lost. Is it possible to call it every time?

I decided this way:
<input data-action="keyup->layouts--systems#filter">


Add wasd camera plugin

I just came to think of French keyboards (AZERTY), as they have ZQSD in place of WASD, and DVORAK keyboards that has <AOE. Maybe Keybind should be used with WASD as default?