fix table cleanup

correctly remove temporal table
remove functions, too

fixes #23

I just added a spec for it and refactored the database support a little bit. I'm not sure why it was namespaced as before, I can change it back if you think it should be.
I got my hands dirty in writing helpers to check if a function and trigger exists in postgresql. I am not sure if this is the cleanest way but this is what I came up with :-)
For mysql though I didn't, because I have no database to test. Could some of the maintainers of the gem maybe try to implement it? Otherwise I will take a look when I find some more time, though I have to install mysql first etc.

There were still some errors for the mysql adapter, because it doesn't create any function but postgresql does. I fixed the code and implemented the trigger check for mysql, too, so now the specs are green and everything should be ready for review here!
Also also marked my other PR as drafts which aren't ready yet (specs missing), so there's no need to review it yet. Some of them are ready for review though: #37, #39, #40 and #43

Thank you!


[Fix #10310] Add InspectBlocksOnAllLevels config param

Add a configuration parameter to Layout/RedundantLineBreak to signal whether blocks on any level (depth) should be inspected. If false, only the innermost level of blocks within blocks will be inspected. If true, all levels will be inspected.
To achieve backwards compatibility, the default value for the new parameter is set to true.

I get the idea behind this change, but I can't imagine who would ever want to set something like this. Essentially we're adding a config option to keep supporting a bug, which sets a dangerous precedent. I'm against going in this direction, but as usual I'm open to hear what the other @rubocop/rubocop-core members think as well.

I agree with @bbatsov opinion. I wonder whether it's a general style that should be enforced in exchange for complex configuration.

Fair enough. Added complexity for minimal gain.
No problem for me to close this one.


Support for PNG cover/track art files

@Niklink wrote (27 Feb 2022)

Currently thumbnails are correctly generated from PNGs, but trying to view fullsize art leads to a 404 because it always links to a JPG even when there isn't one. Lossy medium/small size files are fine but full size art should be archival quality if available.

Added in 3bbeea69c6356edd5792ac7898b9623c2e1519de!
Uses these new fields:

Cover Art File Extension (for albums, tracks, and flashes)
Track Art File Extension (for albums - tracks will inherit this automatically)
Avatar File Extension (for artists)

(06 Mar 2022)


CacheManager.isAuthorityMetadata blocks main thread

Core Library
MSAL Node (@azure/msal-node)
Core Library Version
1.9.0
Wrapper Library
Not Applicable
Wrapper Library Version
0
Description
We observe isolated but regular performance bottlenecks for about 2-3 weeks now, caused by a blocked main thread in a node.js application. According to the CPU profile recorded during the outages, node gets stuck on validating CacheManager.isAuthorityMetadata:

Error Message
No response
Msal Logs
No response
MSAL Configuration
{
  auth: {
    clientId: CLIENT_ID,
    authority: 'https://login.microsoftonline.com/common',
    knownAuthorities: [],
    redirectUri: REDIRECT_URI,
    postLogoutRedirectUri: `${REDIRECT_URI}/logout`,
    navigateToLoginRequestUrl: true,
  },
  cache: {
    cacheLocation: 'sessionStorage',
    storeAuthStateInCookie: false,
  },
}

Relevant Code Snippets
private async getAccessToken(token: string) {
    const result = await this.confidentialClient.acquireTokenOnBehalfOf({
      oboAssertion: token,
      scopes: ['https://graph.microsoft.com/.default'],
    })

    return result?.accessToken
  }

Reproduction Steps

God only knows
This issue happens 1-2 times per day while having a couple of hundreds of users active daily

Expected Behavior
protected isAuthorityMetadata(key: string): boolean {
    return key.indexOf(AUTHORITY_METADATA_CONSTANTS.CACHE_KEY) !== -1;
}

I'm bamboozled about how a string lookup like this could block the main thread? Any help is highly appreciated
Identity Provider
Azure AD / MSA
Browsers Affected (Select all that apply)
Other
Regression
No response
Source
External (Customer)

I am unable to reproduce it on my end. Is this still persistent?


No horizontal scrolling

Hello,
I notice that horizontal scrolling is not working with this theme (with default theme, this is done the right way).
Though vertical scrolling is working.
Thanks !

Sorry, when I add 'react-sortable-tree/style.css' with this theme. It's working !


Type safety for datatable

I would like to have type safety for dataTable.
Given("the user logged into to the tenant portal", (dataTable: DataTable) => {
   ...
});

The dataTable object seems to come from cucumber.js. I'm assuming there is no typescript definition for it?

I'm assuming there is no typescript definition for it?

Not in the version of cucumber that the preprocessor currently depends on.

It's true that cucumber.js doesn't have type DataTable until version 7, but we should be able to use TableDefinition instead?
7.0.0-rc.0 (2020-09-14)
Starting with version 7, the npm module has been changed from cucumber to @cucumber/cucumber

Migration guide:

npm uninstall cucumber
npm install --save-dev @cucumber/cucumber
require/import @cucumber/cucumber instead of cucumber
TypeScript
Replace TableDefinition with DataTable

Should it be expose through @types/cypress-cucumber-preprocessor?

Should it be expose through @types/cypress-cucumber-preprocessor?

Yes, I absolutely think it should, provided that we produce it (which we do)-

Should it be expose through @types/cypress-cucumber-preprocessor?

Yes, I absolutely think it should, provided that we produce instances of it (which we do).

I ran into this https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/pull/385 while I was looking to add TableDefinition to @types/cypress-cucumber-preprocessor
It looks like @lgandecki made a decision to update the types in cypress-cucumber-preprocessor instead of @types/cypress-cucumber-preprocessor. Reading the thread there was a preference to have a single source of truth. Considering the history is this still the way to go?

Considering the history is this still the way to go?

Two sources of truth? No. Let me be frank here and excuse my lack of patience. I dislike our use of DefinitelyTyped. In fact, I fact, despise it. I understand the motivation behind DefinitelyTyped and why is it necessary, but I wish it wasn't like that. I would like for us to ship our own types, which would be correlated to version and not be subject to a mismatch game that there currently is.
I wish I could say more in response, something more useful. Truth is that we're going to have to make a decision about the way forward, ref. #322.

I agree, having two sources of truth is awful and being able to just emit correct types based on code would (and I hope will) be the way to go.

What am hearing from you guys is adding TableDefinition to @types/cypress-cucumber-preprocessor is not the correct long term solution but what about using it as a short term solution?

Same question - any progress here? Would be great to be able to have it typed.

Due to personal reasons, the previous maintainers of this package are stepping down and handing the reigns over to me, a long-time contributor to the project and a user of it myself. This is a responsibility I'm very excited about. Furthermore, I'd like to thank @lgandecki ++ for all the work that they've done so far.
Read more about the transfer of ownership here.
The repository has however moved and all outstanding issues are being closed. This is not a reflection of the perceived importance of your reported issue. However, if after upgrading to the new version, you still find there to be an issue, feel free to open up another ticket or comment below. Please make sure to read CONTRIBUTING.md before doing so.

Sorry, I know it's closed, but is the conclusion that it's not possible to type datatable?

No, it’s typed since the rewrite. Take a look at the exported members.


Fix for RTMPProtocolDecoder failure when media chunks cross RTMPT requests

The bug can be reproduced as follows:

Connect to Red5 using RTMPT or RTMPS:

var nc:NetConnection = new NetConnection();
nc.connect('rtmpt://example.com:5080/application');

After the connection is made, start recording video using a buffer:

var ns:NetStream = new NetStream(nc);
ns.bufferTime(60);
ns.attachCamera(camera);
ns.attachAudio(mic);
ns.publish('streamid', 'record');

Record until there are few seconds of buffer (it helps to slow down your upload speed with tc or similar), then stop and wait for the buffer to drain as follows:

// disconnect sources to allow buffer to drain
ns.attachCamera(null);
ns.attachAudio(null);
// wait for the buffer to be empty and close the stream
setInterval(function():void {
  if (! (ns.bufferLength > 0.0)) {
    ns.close();
  }
}, 500);

Note that Red5 does not close and finalize the stream until the connection closes.

After examining trace output, I understand the mechanism like this:
When the connection begins draining in step 3, it's no longer bound by real-time constraints, so chunks are sent as fast as possible. There seems to be a size limit of 8192 bytes per request, and the Flash client will fill this completely if it can. Since this is not an even multiple of common chunk sizes (e.g. 258 bytes), partial chunks appear at the ends of requests.
In the main loop of RTMPProtocolDecoder.decodeBuffer, an instance of RTMPDecodeState is used to track state. This state persists across calls, and the only place it's cleared is here:
if (state.canStartDecoding(remaining)) {
  log.trace("Can start decoding");
  state.startDecoding();
} else {
  log.trace("Cannot start decoding");
  break;
}

Now, suppose a large buffer is decoded and goes into the buffered state on its final chunk. After the final chunk has been processed, the state is left in RTMPDecodeState.DECODER_BUFFER for the next chunk, since we exit the loop and state.startDecoding() is not called again. If the next buffer is sufficiently large, there's no problem, but suppose we get a small buffer containing the closeStream command, which is what happens in the reproduction method above. The state.canStartDecoding test fails, and we wind up waiting until more data comes in, which it won't since recording is finished, so the closeStream call is never parsed.
I can't claim to understand this state machine well enough to suggest a perfect fix, but I've made a patch that seems to work by calling state.startDecoding() before entering the decode loop, like so:
// get the local decode state
RTMPDecodeState state = conn.getDecoderState();
state.startDecoding(); // <= add this line to initialize the state
log.trace("RTMP decode state {}", state);

This does seem to fix the issue without causing other problems. Since the unparsed portion of the previous buffer should be available at this point, I think the only consequence will be to re-read the chunk header at the start of the buffer, and only on the first pass through the loop. However, I haven't tested extensively enough to rule out unintended side effects, which is why I'm filing this as an issue rather than a fork and pull request.

My proposed fix actually causes errors that end the connection in some cases. I'll investigate this, but I believe my analysis of the problem is still close to the mark.

Thanks for digging into this, we await your final analysis.

@mondain I believe I have found the root cause.
I recorded a problematic series of inputs to BaseRTMPTConnection.decode and simulated its action in TestRTMPProtocolDecoder. However, the problem did not occur under test. This suggested that the problem had nothing to do with buffer content. I then instrumented the method by adding this to the end:
        log.warn("start {}: {}", System.identityHashCode(this.getDecoderState()), this.getDecoderState());
        List<?> result = decoder.decodeBuffer(this, buffer);
        log.warn("finish {}: {}", System.identityHashCode(this.getDecoderState()), this.getDecoderState());
        return(result);

This reveals output like the following from the end of a recording session (simplified for clarity):
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Ok, decoderBufferAmount=0]
...
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]
...
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]

So we can see that although the first of these left the state with no pending data, the second two did not. Note that all three have different identity hashes for the state object. Filtering for one of these, we can see that state is consistent for each instance of RTMPDecodeState:
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Ok, decoderBufferAmount=0]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Ok, decoderBufferAmount=0]
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Ok, decoderBufferAmount=0]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Ok, decoderBufferAmount=0]
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Ok, decoderBufferAmount=0]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=265]
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=265]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]
start<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]
finish<PHONE_NUMBER>: RTMPDecodeState [sessionId=2BBSZBQNDCHY0, decoderState=Buffer, decoderBufferAmount=258]

I believe this is a design flaw in how the decode state is stored. From RTMPConnection.java:
    // keeps track of the decode state
    protected transient ThreadLocal<RTMPDecodeState> decoderState = new ThreadLocal<RTMPDecodeState>() {

        @Override
        protected RTMPDecodeState initialValue() {
            return new RTMPDecodeState(getSessionId());
        }

    };

So although there's only one instance of the buffer per connection instance, the state which contains information essential for parsing that buffer is stored on a per-thread basis, and evidently threads are being allocated from a pool. If this design is meant to ensure thread safety, it's undermined by the fact that BaseRTMPTConnection.decode does not itself appear to be thread-safe, i.e. there's nothing guarding against flipping the buffer while it's being decoded, or multiple decoders addressing the same buffer at the same time.
I can see at least two ways to resolve this:

Treat the decoder state as local to RTMPProtocolDecoder.decodeBuffer, and re-acquire state from the buffer if needed.
Guarantee there can only be one RTMPDecodeState instance per RTMPConnection instance.

However, I'm not sure what's best given the wider context of the project.

I'd say number 2 is best: Guarantee there can only be one RTMPDecodeState instance per RTMPConnection instance.

Modified to fit option 2 in 1.0.9-SNAPSHOT


Migrate to go 1.18

Bumped go version 1.18
Bumped mockery to 2.13.1 (v2):

Mockery version 1.x is not compatible with golang 1.18. Version 2 however include changes to the CLI that are not backwards compatible, thus causing the generated files from go-swagger to fail to generate when invoking go generate ./... The commit includes the go-swagger templates for the client and server that containt the correct mockery command flags.
Bumped references to golang 1.18 in the Makefile to handle the import target

Regenerated files from running go-swagger and mockery
Revert commit that instructed gosec to never fail on error

At some point, I think that we discussed this in the past, and it was an issue with the code imported by device worker. , so I highly suggest that check that import is working as expected.

Tested device worker against 1.18 without changes to the flotta-operator package version and it seems to work fine. I did run go get -u ./.../ but it only changed the indirect dependencies. Do you remember where did you find the issues?
Here is the PR for device-worker with go 1.18.

Summary of this PR:

The main bulk is changes in the go.mod and dependencies to migrate to go 1.18, including bumping mockery version to the latest (currently using 1.1.2, which is deprecated). Many files changed, blame go mod tidy and go mod download :smile:, I'm just the messenger :wink:
Fixes the gosec issues with go 1.18 that we faced earlier and we patched by adding the flag to not to fail when error. However I discovered that to fix this issue we don't require to migrate the project to go 1.18, just add the env variable GOFLAGS: -buildvcs=false in the step and it take care of it.

Are we comfortable migrating to go 1.18 and including the fix for gosec? or should we take them apart and merge them independently?
And I tested migrating the device-worker to go 1.18 and it was quite a straight task: https://github.com/project-flotta/flotta-device-worker/pull/180
Thoughts? @eloycoto @jakub-dzon @machacekondra @pkliczewski @gabriel-farache @tupyy @masayag

At some point, I think that we discussed this in the past, and it was an issue with the code imported by device worker. , so I highly suggest that check that import is working as expected.

Tested device worker against 1.18 without changes to the flotta-operator package version and it seems to work fine. I did run go get -u ./.../ but it only changed the indirect dependencies. Do you remember where did you find the issues? Here is the PR for device-worker with go 1.18.

IIRC, @tupyy encountered compatibility issue with device-worker and go-1.18

Summary of this PR:

The main bulk is changes in the go.mod and dependencies to migrate to go 1.18, including bumping mockery version to the latest (currently using 1.1.2, which is deprecated). Many files changed, blame go mod tidy and go mod download smile, I'm just the messenger wink
Fixes the gosec issues with go 1.18 that we faced earlier and we patched by adding the flag to not to fail when error. However I discovered that to fix this issue we don't require to migrate the project to go 1.18, just add the env variable GOFLAGS: -buildvcs=false in the step and it take care of it.

Are we comfortable migrating to go 1.18 and including the fix for gosec? or should we take them apart and merge them independently?
And I tested migrating the device-worker to go 1.18 and it was quite a straight task: project-flotta/flotta-device-worker#180
Thoughts? @eloycoto @jakub-dzon @machacekondra @pkliczewski @gabriel-farache @tupyy @masayag

I'd break into two pieces (one to handle gosec which can be merged instantly, and a second PR for 1.18)

At some point, I think that we discussed this in the past, and it was an issue with the code imported by device worker. , so I highly suggest that check that import is working as expected.

Tested device worker against 1.18 without changes to the flotta-operator package version and it seems to work fine. I did run go get -u ./.../ but it only changed the indirect dependencies. Do you remember where did you find the issues? Here is the PR for device-worker with go 1.18.

IIRC, @tupyy encountered compatibility issue with device-worker and go-1.18

It is not go1.18 per se the problem. It is the standard library that can cause some issues. There are small differences between std lib 1.17 and 1.18 and we need to be careful using dependencies that don't support 1.18

Summary of this PR:

The main bulk is changes in the go.mod and dependencies to migrate to go 1.18, including bumping mockery version to the latest (currently using 1.1.2, which is deprecated). Many files changed, blame go mod tidy and go mod download smile, I'm just the messenger wink
Fixes the gosec issues with go 1.18 that we faced earlier and we patched by adding the flag to not to fail when error. However I discovered that to fix this issue we don't require to migrate the project to go 1.18, just add the env variable GOFLAGS: -buildvcs=false in the step and it take care of it.

Are we comfortable migrating to go 1.18 and including the fix for gosec? or should we take them apart and merge them independently?
And I tested migrating the device-worker to go 1.18 and it was quite a straight task: project-flotta/flotta-device-worker#180
Thoughts? @eloycoto @jakub-dzon @machacekondra @pkliczewski @gabriel-farache @tupyy @masayag

I'd break into two pieces (one to handle gosec which can be merged instantly, and a second PR for 1.18)

I second that
About the regression we may face with the device-worker, I guess you ran the e2e tests so if there was no error we should be fine. And if we are not, this will be the occasion to improve the e2e tests are they are supposed give us confidence on impact of changes on the operator to the overall workflow
Overall, it's a good idea to keep up with the new version once it's been released for a few month (to see if there is anyu bugs), even more with go 1.18 that brings generics!

TBH, with the low resources that the project will have over the next months and the possible problems that 1.18 dependencies will bring to the device worker until I saw a big change that will make our life much better, I'll keep Golang version as it is. IMHO.

Overall, it's a good idea to keep up with the new version once it's been released for a few month (to see if there is any bugs), even more with go 1.18 that brings generics!

Not sure if generics, as it is now, is useful for flotta at all. There are use cases sure, but without generics on structs methods I do not think that adds too much value as the project is now. IMHO


Add final to method input params - beacon module

PR Description
This is PR is part of a series where the aim is to add missing final to enable the MethodInputParametersMustBeFinal error prone validation.
Fixed Issue(s)

Documentation

[x] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[x] I thought about adding a changelog entry, and added one if I deemed necessary.

Only for method inputs?

That's a good point. I believe we are only applying MethodInputParametersMustBeFinal. @gfukushima could you check if we have one for member variables and local variables that can be final as well?

The EP check for finals in variables is a different one (FieldCaBeFinal) and we should probably enable it as well. I'd like to avoid mixing those for now but I do plan to submit a PR to enable that as well


502 Bad Gateway (debian jessie)

With Debian 8, on subdirectory : 502 Bad Gateway
In log:
2015/06/02 13:00:15 [error] 23757#0: *115673 connect() failed (111: Connection refused) while connecting to upstream, client: <IP_ADDRESS>, server: gogs.example.net, request: "GET /gogs/ HTTP/1.1", upstream: "http://<IP_ADDRESS>:6000/", host: "gogs.example.net"
2015/06/02 13:00:15 [error] 23757#0: *115673 connect() failed (111: Connection refused) while connecting to upstream, client: <IP_ADDRESS>, server: gogs.example.net, request: "GET /gogs/ HTTP/1.1", upstream: "http://[::1]:6000/", host: "gogs.example.net"

Should be fixed with #10

I actually have this issue on the same system. As it's not marked as resolved, I post the log here :
2015/11/15 22:42:51 [error] 19340#0: *2488 connect() failed (111: Connection refused) while connecting to upstream, client: 2a0:a03f:c76:d80:ea2a:eaff:fe3a9c3, server: git.hiserver.tld, request: "GET /_/ HTTP/1.1", upstream: "http://[::1]:6000/", host: "git.hiserver.tld", referrer: "https://hiserver.tld/yunohost/admin/"
In anytime, even if I reinstall the app, I have the very same error: 502 - bad gateway
Is there a fix before an update ?

This issue refer to an old version of the package so it's probably a different 502 error ;) This is a generic server side error and most of the times it happens when the app is not started.
Anyway, did you try to start the service manually with systemctl restart gogs.service ?
It seems that sometimes at computer restart the service does not start properly. You can also look at gogs's log in /var/log/gogs and with journalctl -u gogs to see if there is something interesting. I do not have time to look into this this week but please keep me in touch with your investigations.

Okay then. I'll make another issue. Then it'll be clearer.


Change Interactor#call to receive a partial context via keyword arguments

class MyInteractor
  include Interactor

  def call(email:, password:, remember_me: false)
    # …
  end
end

Implemented in #135.

@laserlemon should this be closed since the PR referenced hasn't been closed?


update go mod

fix cannot unmarshal number 1715.0 into Go struct field StatsData.data.daily_average of type int64

#38


Missing or needless dependency on tf?

I am trying to follow the installation instructions and I fail on the catkin_call. It appears that we have a dependency on tf, but I don't know exactly where.  I think this dependency should not be there, but @henrik7264 try to convince me (then we should put it in package.xml).
Or do I misinterpret the error message @gavanderhoorn ?
wasowski@research104:~/work/rx_ros_ws$ docker run -it ros
root@6aaceb91be0e:/# mkdir rxros_ws
root@6aaceb91be0e:/# cd rxros_ws/
root@6aaceb91be0e:/rxros_ws# ls
root@6aaceb91be0e:/rxros_ws#  wstool init src https://raw.githubusercontent.com/rosin-project/rx_ros/master/rosinstall.yaml
Using initial elements from: https://raw.githubusercontent.com/rosin-project/rx_ros/master/rosinstall.yaml
Writing /rxros_ws/src/.rosinstall
[rx_ros] Fetching https://github.com/rosin-project/rx_ros (version None) to /rxros_ws/src/rx_ros
Cloning into '/rxros_ws/src/rx_ros'...
remote: Enumerating objects: 257, done.
remote: Counting objects: 100% (257/257), done.
remote: Compressing objects: 100% (176/176), done.
remote: Total 257 (delta 91), reused 231 (delta 73), pack-reused 0
Receiving objects: 100% (257/257), 250.41 KiB | 925.00 KiB/s, done.
Resolving deltas: 100% (91/91), done.
[rx_ros] Done.

update complete.
root@6aaceb91be0e:/rxros_ws# catkin_make
Base path: /rxros_ws
Source space: /rxros_ws/src
Build space: /rxros_ws/build
Devel space: /rxros_ws/devel
Install space: /rxros_ws/install
Creating symlink "/rxros_ws/src/CMakeLists.txt" pointing to "/opt/ros/melodic/share/catkin/cmake/toplevel.cmake"
####
#### Running command: "cmake /rxros_ws/src -DCATKIN_DEVEL_PREFIX=/rxros_ws/devel -DCMAKE_INSTALL_PREFIX=/rxros_ws/install
-G Unix Makefiles" in "/rxros_ws/build"
####
-- The C compiler identification is GNU 7.4.0
-- The CXX compiler identification is GNU 7.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: /rxros_ws/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/melodic
-- This workspace overlays: /opt/ros/melodic
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.15", minimum required is "2")
-- Using PYTHON_EXECUTABLE: /usr/bin/python2
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /rxros_ws/build/test_results
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found PythonInterp: /usr/bin/python2 (found version "2.7.15")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.17
-- BUILD_SHARED_LIBS is on
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~  traversing 5 packages in topological order:
-- ~~  - teleop_msgs
-- ~~  - brickpi3_msgs
-- ~~  - rxros
-- ~~  - teleop
-- ~~  - brickpi3
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ processing catkin package: 'teleop_msgs'
-- ==> add_subdirectory(rx_ros/examples/teleop_msgs)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- teleop_msgs: 2 messages, 0 services
-- +++ processing catkin package: 'brickpi3_msgs'
-- ==> add_subdirectory(rx_ros/examples/brickpi3_msgs)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- brickpi3_msgs: 7 messages, 0 services
-- +++ processing catkin package: 'rxros'
-- ==> add_subdirectory(rx_ros/rxros)
-- +++ processing catkin package: 'teleop'
-- ==> add_subdirectory(rx_ros/examples/teleop)
-- +++ processing catkin package: 'brickpi3'
-- ==> add_subdirectory(rx_ros/examples/brickpi3)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Could NOT find tf (missing: tf_DIR)
-- Could not find the required component 'tf'. The following CMake error indicates that you either need to install the pac
kage with the same name or change your environment so that it can be found.
CMake Error at /opt/ros/melodic/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
  Could not find a package configuration file provided by "tf" with any of
  the following names:

    tfConfig.cmake
    tf-config.cmake

  Add the installation prefix of "tf" to CMAKE_PREFIX_PATH or set "tf_DIR" to
  a directory containing one of the above files.  If "tf" provides a separate
  development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  rx_ros/examples/brickpi3/CMakeLists.txt:10 (find_package)

-- Configuring incomplete, errors occurred!
See also "/rxros_ws/build/CMakeFiles/CMakeOutput.log".
See also "/rxros_ws/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed

Or do I misinterpret the error message @gavanderhoorn ?

No, you're correct.
The brickpi3 package has a build_depend on tf. It also correctly states that here.
What I'm missing in your console output is a rosdep check .. or rosdep install .. step, which would've made sure that the tf package is installed.

I am thinking that it would be nice to factor out the examples to a separate package ...

I am thinking that it would be nice to factor out the examples to a separate package ...

you mean a separate repository? They already are in separate packages.

oh right. of course, my knowledge is short as usual :)
We can only install the entire stack into a workspace, right? Then probably a separate repo.  But I could do turtlesim, or, even a simpler, a publisher/subscriber example, to minimize deps for packages included in the repo; How this is normally done in ROS?

Examples are certainly always in a separate package. Sometimes in a separate repository.
A good example of this is the ros_tutorials repository. It contains demo packages for a nr of client libraries and other ROS related infrastructure. We could create something similar.
The teleop example seems relatively stand-alone though. That could probably be kept with the package in this repository.

Related: #5.

The rxros library is very thin, and it just relates to how roscore api is presented, so I think it would be beneficial to minimize the dependencies on the stack altogether.  People may want to use it on some minimal ros systems.

The teleop example only depends on: roscpp, rxros, std_msgs, teleop_msgs, message_generation, message_runtime and catkin.
That is pretty minimal, and most of those will be part of a minimal ROS installation already.
But I'm fine with moving the examples out of this repository.
It would just require an extra line in the .rosinstall file to check it out in case a user wants a batteries-included experience.

Hi Andrzej and Gijs
Oh my what have I done now. I am on my way home from work. I shall l look at it as soon as I come home.
Regards . Henrik
On 27 Aug 2019, at 17.52, Andrzej Wąsowski <notifications<EMAIL_ADDRESS>wrote:
The rxros library is very thin, and it just relates to how roscore api is presented, so I think it would be beneficial to minimize the dependencies on the stack altogether. People may want to use it on some minimal ros systems.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frosin-project%2Frx_ros%2Fissues%2F3%3Femail_source%3Dnotifications%26email_token%3DAJYMVX5DNGJN4IN4Q7AG7E3QGVESNA5CNFSM4IQE53VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5IG4JI%23issuecomment-525364773&data=02|01||a69f13c52c2246a4f15308d72b0683ce|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025179284627757&sdata=RXu6bsuUEWpFInXZpsIIePrnD%2BDuEjoxLTV14rXWiS4%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJYMVX4ODVJWJACILY3ERJLQGVESNANCNFSM4IQE53VA&data=02|01||a69f13c52c2246a4f15308d72b0683ce|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025179284647773&sdata=CxnlXF2%2BaAtXNUqBUrTr3ptHS3vUBqszrxlrDehEOI0%3D&reserved=0.

Don't worry Henrik.  We are just trying to help.  First look at the PR that @gavanderhoorn has sent you.
@gavanderhoorn , I think teleop should stay in here, but the brick stuff is way too heavy for the standard distribution.

I think teleop should stay in here, but the brick stuff is way too heavy for the standard distribution.

agreed.

My joy was premature.  The core file rxros.h has a direct dependency on tf
static auto from_transform(const std::string& parent_frameId,
     const std::string& child_frameId,
     const double frequencyInHz = 10.0)

The build without examples succeeds, because bare bones header files always compile :). It is nice to have at least one example in the same repo as we force compilation and detect dependency bugs.
Since it is the core thing that depends on tf, I think we should maintain the dependency first.  And once the release is tiedied up, we can refactor rxros_tf from rxros. Is this the right course of action @gavanderhoorn or am I being paranoid?

The build without examples succeeds, because bare bones header files always compile :). It is nice to have at least one example in the same repo as we force compilation and detect dependency bugs.

Agreed.

Since it is the core thing that depends on tf, I think we should maintain the dependency first. And once the release is tiedied up, we can refactor rxros_tf from rxros. Is this the right course of action @gavanderhoorn or am I being paranoid?

No, your concern is very much justified.
I would go even further and say that we should create a rxros_tf immediately and just factor it out before even releasing rxros. One additional package takes only a small amount of time and it would very cleanly split dependencies in a sensible way.

Hi Andrzej and Gijs,
I remembered similar problems from the past. There are as I remember it three ways to install ROS Melodic:
ros-melodic-desktop-full
ros-melodic-desktop
ros-melodic-ros-base
I have always used the "ros-melodic-desktop-full” installation to avoid these dependencies problems. Especially the examples sources requires both messages and tf from the desktop-full installation
I don’t know if it is to much to require?
On 27 Aug 2019, at 17.59, Henrik Larsen <henrik7264<EMAIL_ADDRESS>wrote:
Hi Andrzej and Gijs
Oh my what have I done now. I am on my way home from work. I shall l look at it as soon as I come home.
Regards . Henrik
On 27 Aug 2019, at 17.52, Andrzej Wąsowski <notifications<EMAIL_ADDRESS>wrote:
The rxros library is very thin, and it just relates to how roscore api is presented, so I think it would be beneficial to minimize the dependencies on the stack altogether. People may want to use it on some minimal ros systems.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frosin-project%2Frx_ros%2Fissues%2F3%3Femail_source%3Dnotifications%26email_token%3DAJYMVX5DNGJN4IN4Q7AG7E3QGVESNA5CNFSM4IQE53VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5IG4JI%23issuecomment-525364773&data=02|01||a69f13c52c2246a4f15308d72b0683ce|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025179284627757&sdata=RXu6bsuUEWpFInXZpsIIePrnD%2BDuEjoxLTV14rXWiS4%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJYMVX4ODVJWJACILY3ERJLQGVESNANCNFSM4IQE53VA&data=02|01||a69f13c52c2246a4f15308d72b0683ce|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025179284647773&sdata=CxnlXF2%2BaAtXNUqBUrTr3ptHS3vUBqszrxlrDehEOI0%3D&reserved=0.

Hi Gijs and Andrzej,
I am actually a bit sorry for moving the examples. They do provide different examples of how RxROS can be applied to solve more complex problems. I would actually like to end up with a full example of a LEGO robot that is based on RxROS.
I agree that it is not especially nice that they can not compile without the ros-melodic-desktop-full installation. Is your expectation that  rx_ros can be build using only ros-melodic-ros-base ?
What do you intend to put in the rxros_tf package? I am not sure if I can follow you here?
/Henrik
On 27 Aug 2019, at 18.20, G.A. vd. Hoorn <notifications<EMAIL_ADDRESS>wrote:
The build without examples succeeds, because bare bones header files always compile :). It is nice to have at least one example in the same repo as we force compilation and detect dependency bugs.
Agreed.
Since it is the core thing that depends on tf, I think we should maintain the dependency first. And once the release is tiedied up, we can refactor rxros_tf from rxros. Is this the right course of action @gavanderhoornhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgavanderhoorn&data=02|01||bbab866784614ae6da5f08d72b0a8a64|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025196576798130&sdata=xk%2B0s%2F8Rb0HBatp5bqlFclR14C5nq5Qw99NhsfBxOr8%3D&reserved=0 or am I being paranoid?
No, your concern is very much justified.
I would go even further and say that we should create a rxros_tf immediately and just factor it out before even releasing rxros. One additional package takes only a small amount of time and it would very cleanly split dependencies in a sensible way.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frosin-project%2Frx_ros%2Fissues%2F3%3Femail_source%3Dnotifications%26email_token%3DAJYMVX7LC6RFWSHCVDVRI3TQGVH6RA5CNFSM4IQE53VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5IJ3VA%23issuecomment-525376980&data=02|01||bbab866784614ae6da5f08d72b0a8a64|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025196576808124&sdata=7sjrsH%2Bfcty%2F6gGEiXc4lcM6kSXl6hWX9ygNMe1OksI%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJYMVXYVEK7MB5EW3RUWJU3QGVH6RANCNFSM4IQE53VA&data=02|01||bbab866784614ae6da5f08d72b0a8a64|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025196576818135&sdata=Gx6kWq4CuiOow9hAbQ9eCOvMKWg6lPwi0Pr04eNWxxQ%3D&reserved=0.

@henrik7264: the package.xml file supports specifying the dependencies of a package very precisely. The rxros package manifest should simply state it depends on tf. Any user building from source could then use rosdep to install all required dependencies automatically. The buildfarm would be able to automatically figure out which packages are needed to properly build the package as well.
We must do this, as otherwise a release would be impossible (the buildfarm is automated, it does not read your readme).

I have always used the "ros-melodic-desktop-full” installation to avoid these dependencies problems. Especially the examples sources requires both messages and tf from the desktop-full installation
I don’t know if it is to much to require?

a ros-melodic-desktop-full install is gigabytes in size (and includes things such as Gazebo). Besides installing many unneeded packages, it's also rather wasteful, when a simple dependency on tf would completely solve all the problems.
Personally, I would say "yes, installing all of ros-melodic-desktop-full just to be able to depend on tf is too much".

I am actually a bit sorry for moving the examples. They do provide different examples of how RxROS can be applied to solve more complex problems. I would actually like to end up with a full example of a LEGO robot that is based on RxROS.

Putting packages in a separate repository does not mean that they disappear. In fact, the exact location of packages doesn't really matter: wstool will happily clone repositories from wherever you desire, and this is all opaque to the user.
We're not deleting or destroying the examples, but are trying to make it easier to depend on rxros when users don't want or need the examples. Storing them in a separate repository makes this somewhat easier to achieve.

I agree that it is not especially nice that they can not compile without the ros-melodic-desktop-full installation. Is your expectation that rx_ros can be build using only ros-melodic-ros-base ? What do you intend to put in the rxros_tf package? I am not sure if I can follow you here?

rxros_tf would probably contain a single header that contains the from_transform(..) function.
Users not interested in TF could ignore that package and would only need roscpp installed. Users that are interested in TF would have both rxros and rxros_tf installed (the latter depending on the former). This is a very common pattern in ROS used to avoid introducing unnecessary or unwanted dependencies and is relatively low-overhead.

Hi Gijs & Andrzej,
Thanks Gijs for the excelent explanation - it helped me a lot. I must admit I am very happy with the contents of current workspace/project, but OK it gives good meaning to separate the examples from the library. It will be a clean separation. I will not leave any examples in rx_ros. I will however update the README.md file and explain how to install a build the examples. You are welcome to create a rx_ros_examples project or something similar (you are also welcome to remove the rx_ros-release project - I don’t think we will need that any more)
I will play a bit with the rxros_tf. I am not entirely happy about the solution as I think we are on the road too complicated setup/installation. What would you instead say to a

A solution with a dependent build option?
A solution with 2 installation files (I am not entirely sure this is a good idea - it depends a on how flexible the installation.yaml files are)?
Remove the from_transform entirely - for the moment?

I will try to get the separation finished tomorrow and include your comments.
/Henrik
On 27 Aug 2019, at 21.06, G.A. vd. Hoorn <notifications<EMAIL_ADDRESS>wrote:
@henrik7264https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhenrik7264&data=02|01||b3f57d22c25c4f80d98e08d72b21b497|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025296065169005&sdata=cRtvbRVz%2B%2B44NW0kNoTjDjP2QX%2FVbwjWpnI%2BUhYN0WA%3D&reserved=0: the package.xml file supports specifying the dependencies of a package very precisely. The rxros package manifest should simply state it depends on tf. Any user building from source could then use rosdep to install all required dependencies automatically. The buildfarm would be able to automatically figure out which packages are needed to properly build the package as well.
We must do this, as otherwise a release would be impossible (the buildfarm is automated, it does not read your readme).
I have always used the "ros-melodic-desktop-full” installation to avoid these dependencies problems. Especially the examples sources requires both messages and tf from the desktop-full installation
I don’t know if it is to much to require?
a ros-melodic-desktop-full install is gigabytes in size (and includes things such as Gazebo). Besides installing many unneeded packages, it's also rather wasteful, when a simple dependency on tf would completely solve all the problems.
Personally, I would say "yes, installing all of ros-melodic-desktop-full just to be able to depend on tf is too much".
I am actually a bit sorry for moving the examples. They do provide different examples of how RxROS can be applied to solve more complex problems. I would actually like to end up with a full example of a LEGO robot that is based on RxROS.
Putting packages in a separate repository does not mean that they disappear. In fact, the exact location of packages doesn't really matter: wstool will happily clone repositories from wherever you desire, and this is all opaque to the user.
We're not deleting or destroying the examples, but are trying to make it easier to depend on rxros when users don't want or need the examples. Storing them in a separate repository makes this somewhat easier to achieve.
I agree that it is not especially nice that they can not compile without the ros-melodic-desktop-full installation. Is your expectation that rx_ros can be build using only ros-melodic-ros-base ? What do you intend to put in the rxros_tf package? I am not sure if I can follow you here?
rxros_tf would probably contain a single header that contains the from_transform(..) function.
Users not interested in TF could ignore that package and would only need roscpp installed. Users that are interested in TF would have both rxros and rxros_tf installed (the latter depending on the former). This is a very common pattern in ROS used to avoid introducing unnecessary or unwanted dependencies and is relatively low-overhead.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frosin-project%2Frx_ros%2Fissues%2F3%3Femail_source%3Dnotifications%26email_token%3DAJYMVX6RDPNPZGMT3UE4TTLQGV3MJA5CNFSM4IQE53VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5IZRAA%23issuecomment-525441152&data=02|01||b3f57d22c25c4f80d98e08d72b21b497|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025296065179004&sdata=yKC3a4Uy9nPIJVOHKqrFf4b%2FYE5aQhmgNfl9I1qA3vI%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJYMVX6E4ZZRGL5XPRGAT2DQGV3MJANCNFSM4IQE53VA&data=02|01||b3f57d22c25c4f80d98e08d72b21b497|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637025296065189009&sdata=%2BLjXOEa4xd4miU6fjnvQ2%2BQ4xAYHWb4hh1aLwhS2AxQ%3D&reserved=0.

My suggestions:

create a separate rx_ros_examples repository (I will do this)
move all readme content that discusses the examples, their dependencies and other details to the readme of rx_ros_examples
point to the new rx_ros_examples repository from the rx_ros readme

that way the base library in rx_ros is very simple to setup, setup/installation is very easy to grok and the release process of rxros is also straightforward.

I will play a bit with the rxros_tf. I am not entirely happy about the solution as I think we are on the road too complicated setup/installation.

I realise it may seem that way, but consider this:

.rosinstall files can point to multiple repositories easily, while it's still a single command to clone everything (the same wstool merge ..)
physical package location is opaque to users anyway (that's the whole point of the file system abstraction in ROS)
once a package is released, it's VCS location becomes irrelevant (and the buildfarm also doesn't care)
splitting packages like this is a very common design pattern in ROS (compare tf2, tf2_ros, tf2_py, tf2_eigen, etc). Users will be accustomed to this.

you are also welcome to remove the rx_ros-release project - I don’t think we will need that any more)

I believe we do: rx_ros (without the examples) should be releasable through the buildfarm. I'm currently working on packaging RxCpp itself as a ROS package (very thin wrapper) which would remove the need to copy the headers here in this repository (easier tracking of upstream changes, easier licensing, etc) and allows us to depend on it from rxros.

I will try to get the separation finished tomorrow and include your comments.

Could you please first look at #7?

And #13.

Here is another proposal to the tf problem. My biggest concern about splitting the rxros library is:

The library files get scattered/spread to different packages. I like the idea that they are contained in one directory. Future development of the library will profit from this.
The end user will have to make a decision whether he wants the tf or just the core version. Over time this concept will just be more and more complicated. The end user should not need to take such decisions.

So here is another  proposal. It is not completely implemented, but the basic features are working. The proposal is not without problems, but lets look at them later. Here is the proposal:

The overall idea is to have a rxros_config.h file that the rxros.h will include. The rxros_config.h could look as follows (slightly simplified) on a machine where the ROS tf packages are installed:

#ifndef RXROS_CONFIG
#define RXROS_CONFIG

#define ROS_TF_VERSION 1.12.0

#endif

The rxros_config.h file will allow us to control what should be enabled or not in the rxros.h file.

The rxros_config.h will be generated by a simple script that is executed each time the rxros workspace is build. The script will collect information about what is installed on the users machine and create a number of define statements that can be used in the rxros.h file to include/exclude code.

The bad thing about this solution is the rxros workspace will have to be rebuild each time the user changes his ROS installation. The other bad thing is the code will contain several conditional statements like #ifdef ROS_TF_VERSION - I personally hate this kind of code, but I think I can organize the code so it will look nice and easy to maintain.
Can you follow me and what do you think about the idea?

If I understand you correctly, you'd like to:

add a file that allows the user to configure whether or not the TF functionality should be included
make users edit that file whenever they do want TF
have them recompile their workspace

and not made explicit but:

have users understand the implications of not having TF support enabled in rxros, and
the implications of having it enabled (ie: additional dependencies, etc)

The alternative that was discussed earlier in this thread (and in #8):

adds one additional package (rxros_tf), which
users never touch themselves (only their own code), and which
introduces a single additional header (rxros_tf.h), which
users can choose to #include <rxros_tf/rxros_tf.h> or not, without
changing any code in rxros packages, only their own code/package

Can you follow me and what do you think about the idea?

regardless of my personal opinion, I believe that there are some downsides to your proposal, some of which you've already identified yourself:

users need to recompile code we're providing (ie: rxros)
need to rebuild it when changing the configuration (more work)
we cannot release rxros as a binary through the ROS buildfarm, as that would mean releasing a package where we've already made the choice for them (or actually: the buildfarm)
users of rxros would need to become proficient in building rxros from source, as opposed to just using it as a binary dependency
we'd be introducing #ifdefs into otherwise relatively straightforward code
it would be divergent from accepted ROS design patterns which deal with composability and separation of concerns

The library files get scattered/spread to different packages. I like the idea that they are contained in one directory. Future development of the library will profit from this.

To be fair, the idea in #8 does split up rxros in two parts: one part with and one without tf support. The tf addon cannot be used without the base package.
However, I believe and expect ROS users to be able to deal with this: it's used in other parts of ROS and it's used in non-ROS situations as well (in the end it's essentially the plugin/extension idea, but with packages).

The end user will have to make a decision whether he wants the tf or just the core version. Over time this concept will just be more and more complicated. The end user should not need to take such decisions.

Doesn't the alternative proposal do exactly the same thing (ie: make the user responsible for this configuration choice)? It's just a header with some #ifdefs now, but that's the same as changing your CMakeLists.txt to add another dependency that brings in TF support and adding an #include. But in #8, the changes are only in user code. In this alternative, the user would be changing their own code (using the APIs that use TF) as well as changing your code (== bad, for reasons stated above).

One additional comment on the buildfarm aspect: the alternative makes it rather difficult to release rxros as a binary package. We'd have two choices:

release with TF support
release without TF support

But in reality, we'd only have a single option: release with TF support, as we cannot release the same package twice and in order for everything to keep working, a user must have TF already installed on his system to be able to even have the option to choose to enable it in rxros.
For that we need to add the build and run depend on tf to rxros, otherwise we cannot make sure TF is present on the user's system.
And with that we're back to the initial problem that we started out to solve: avoid installing unnecessary dependencies on the user's system.

Thanks Gijs for all the information. Yes, I agree that my proposed solution by far is optimal. I will let your experience and argumentation in this area come the benefit of the project - so lets go for the rxros_tf package and split the rxros.h file up accordingly. I may not like it, but I may get a pleasant surprise. Please let me know if I can support you in any way.

Thanks Gijs for all the information. Yes, I agree that my proposed solution by far is optimal. I will let your experience and argumentation in this area come the benefit of the project - so lets go for the rxros_tf package and split the rxros.h file up accordingly.

Ok. If it really doesn't work for you, or others, we can always reintegrate everything.

I may not like it, but I may get a pleasant surprise.

Let's hope so.

Please let me know if I can support you in any way.

If you could take a look at #14 and rosin-project/rxros_examples#1 and tell me whether things build and run for you that would be great. We can then proceed to merge it and would have a good basis for further changes.

#24 refactors rxros such that the TF dependency is pushed into a separate package, together with all TF related functionality.
@wasowski: if you could take a look.

Just tested installing rxros and rxros_tf in a clean Melodic Docker container.
I believe the following provides a good justification for why we split the TF support out of the base rxros package.

installing just rxros:
root@16da4763121c:/# apt install ros-melodic-rxros
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  ros-melodic-rxcpp-vendor
The following NEW packages will be installed:
  ros-melodic-rxcpp-vendor ros-melodic-rxros
0 upgraded, 2 newly installed, 0 to remove and 91 not upgraded.
Need to get 94.3 kB of archives.
After this operation, 998 kB of additional disk space will be used.

installing rxros_tf (after having installed rxros itself previously):
root@94eb33a6df9d:/# apt install ros-melodic-rxros-tf
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  fonts-liberation graphviz libann0 libcdt5 libcgraph6 libgd3 libgts-0.7-5 libgts-bin libgvc6 libgvpr2 liblab-gamut1
  libpathplan4 libwebp6 libxaw7 libxmu6 libxpm4 libxt6 ros-melodic-tf ros-melodic-tf2 ros-melodic-tf2-msgs
  ros-melodic-tf2-py ros-melodic-tf2-ros
Suggested packages:
  gsfonts graphviz-doc libgd-tools
The following NEW packages will be installed:
  fonts-liberation graphviz libann0 libcdt5 libcgraph6 libgd3 libgts-0.7-5 libgts-bin libgvc6 libgvpr2 liblab-gamut1
  libpathplan4 libwebp6 libxaw7 libxmu6 libxpm4 libxt6 ros-melodic-rxros-tf ros-melodic-tf ros-melodic-tf2
  ros-melodic-tf2-msgs ros-melodic-tf2-py ros-melodic-tf2-ros
0 upgraded, 23 newly installed, 0 to remove and 91 not upgraded.
Need to get 4007 kB of archives.
After this operation, 16.6 MB of additional disk space will be used.

Note the 16MB vs ~1MB installation size difference.


Unable to set condition on policy statement (following the example)

In the example provided in the README the attribute is called condition:
https://github.com/terraform-aws-modules/terraform-aws-sqs/blob/master/README.md?plain=1#L122
But in the module code the attribute name is different https://github.com/terraform-aws-modules/terraform-aws-sqs/blob/master/main.tf#L70.
Regards.

A proper example is given at https://github.com/terraform-aws-modules/terraform-aws-sqs/blob/master/README.md?plain=1#L84 the one at https://github.com/terraform-aws-modules/terraform-aws-sqs/blob/master/README.md?plain=1#L122 should be fixed since it is simply ignored by the module.


Fix API Service-Account Cert

The API only verifies the token, while the controller-manager issues
it. See https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#token-controller
for more details

Bad naming? https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/04-certificate-authority.md#the-service-account-key-pair

Also, https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/08-bootstrapping-kubernetes-controllers.md#configure-the-kubernetes-api-server

For those following along at home. or in the future, who prefer to read English prose instead of communicating solely through links:
It appears that the problem is that the --service-account-key-file flag doesn't actually want the thing that is traditionally called the "key" in an X.509 certificate / key pair.  Hightower seems to gloss over this in Kubernetes The Hard Way.  The instructions have you generate a key pair, but the two halves get used in the following places:

The key gets used by the controller-manager, since it has to issue the tokens.  This is realized in the --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem flag passed to kube-controller-manager here
The certificate gets used by the apiserver, which has to (I guess?) validate the tokens issued by the controller manager.  This is realized in the --service-account-key-file=/var/lib/kubernetes/service-account.pem flag passed to kube-apiserver here

Perhaps the --service-account-key-file option just suffers from an unfortunate name.  It is possible that this used to be a symmetric key, instead of an asymmetric RSA public/private keypair.  Who knows?
@dmolik if you can check my work above, I'd appreciate the expert eyes. ^_^

Sorry, I was on my phone, and it was easier to post a link.
I'm not sure why Hightower glosses over it, my only guess is, brevity, as he has a section about deploying DNS to the cluster which requires a token. After glancing through the repo issues, I'm still not sure.
I concur on your explanation. While this link, https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#token-controller, discusses the command line, configuration, it doesn't explain why the naming scheme is confusing. I suppose going through the kubernetes repo history might give a better explanation, but alas I'm an Engineer, not a digital history d*****.


Update docker images versions

Update docker images versions to coincide with the Dockerfile at https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/Dockerfile

@jahbenjah  I added versions to the file.


Possibility to export to standard json schema

Hi,
we are considering using this tool for our yaml schemas validation but we rely on being able to produce a standard json schema from a yamale schema for different extensions we use that needs the schema to be supplied in json.
Would it be possible to do this? From YAML to JSON we have no issue at all, but given than yamale introduces new semantics we cannot do it easily ourselves.
Thanks!

Hi, thanks for taking a look at Yamale.
Can you give an example of the errors you're seeing? Yamale schema is valid YAML, so your current converter should work.
Is the issue with the multiple document format that YAML supports? If that's the case, you'll need to save each document on the source side and reconstruct the YAML on the destination side. For example:
schemas = []
with open('your.schema') as f:
    docs = yaml.safe_load_all(f)
    for d in docs:
        schemas.append(d)

Or, you can just base64 encode the whole file, send it as a string in a JSON blob, and decode it on the other end.

Hi and thanks for the quick response! Sorry I could not come back to it earlier.
We are not seeing any specific errors since we are still researching if this would beneficial for us. Let me explain a bit better.
As we udnerstand yamale, it includes richer syntax to use json schema with YAML file making it easier to define our schemas. Yamale will internally understand this rich syntax and behave as a standard json schema file.
We want to use some IDE extensions (like in VsCode) that receive a json schema and validates the file you are writing against the schema and show a visual mark when the schema is not being followed. We have also some tools in place in our CI pipeline that check all of our yaml file against different schemas.
In both cases pointed out before we need to have plain json schema syntax. When using yaml to define schemas it is not a problem because there is a correspondence 1:1 with the json schema files, we can read or schemas in yaml and create a json for them that both the extension and tools will pick naturally. But with yamale, if we would do that, the json file produced out of the yamale schema files won't be recognizable by json schema because the rich syntax is not supported.
My question is that if based on a yamale schema file (using the richer syntax) we could produce the standard json file to be read by json schema. I am not sure if this is clearer than before, but let me know.
Thanks!

Sorry, I'm still having a hard time understanding what you're trying to do. Are you attempting to:

Write yamale schema
Transform that into JSON schema (https://json-schema.org/)
Feed that into VSCode to validate JSON files

I don't understand where the JSON schema comes into play....or how and why you're producing JSON files from the Yamale schema files. If you could also explain what you mean by rich syntax, that may help too.
We wrote Yamale to work with YAML only. Using it for JSON validation, if that's what you're trying to do, would not fit the use cases we'd be will to support.
Let me know if I misunderstood anything. :)

Thanks a lot for the comment. You have now answered my question. Yes, somehow we got the impression that Yamale was using JSON schema behind the scenes. We can already validate YAML using JSON schema and we thought that Yamale was adding richer syntax on top of it to make it simpler.
If this is built from the ground up without any ties with JSON schema I do not think it can fit our project.
Just let me explain since I think now understand better what Yamale is. In JSON you can write a schema like this:
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://example.com/product.schema.json",
  "title": "Product",
  "description": "A product from Acme's catalog",
  "type": "object",
  "properties": {
    "productId": {
      "description": "The unique identifier for a product",
      "type": "integer",
      "minimum": 0,
      "maximum: 10
    },
  "required": [ "productId"]
}

Using JSON schema standard we can validate YAML and even write the schemas themselves in YAML. We thought Yamale was a tool built on top of it to simplify the syntax making things like the productId validation rules easier to read and maintain:
productId: int(min=0, max=10)

We were interested in knowing how we can transform that into the JSON schema standard because we need that JSON schema file for different things.
I understand now that this is not possible. The tool seems pretty cool and I will probably use it in different projects :) sadly for this one we cannot go this way.
Thanks a lot for your time!

Ah, it all makes sense now. :) I'm sorry it won't fit this project, but reach out if you have any questions for integrating into other projects. Thanks!


Navigation to the application Log is not working for background jobs

To connect the application log with a background job, the function module BP_ADD_APPL_LOG_HANDLE should be executed with the log-handle as a parameter, when the log is saved in background mode (sy-batch = abap_true).
IF sy-batch = abap_true.

    CALL FUNCTION 'BP_ADD_APPL_LOG_HANDLE'
        EXPORTING
            loghandle = me->handle
        EXCEPTIONS
            OTHERS    = 0.

ENDIF.

Then the navigation via SM37 and menu Goto / Application Log is working.

Closed by #146


initial work to set up pulling a repo from git

[ ] Address TODO comment on Bash script

One more comment here. When you all are done, please make sure to update the README and examples for the new way to make the Docker images work with platform.


[DS-2909] Fix EPerson netId setter

Was a self assigned variable so the netid could never be set.

+1 obviously correct.

+1 by inspection


Don't fail CI because of grep nomatch

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@64c325a). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #154   +/-   ##
=========================================
  Coverage          ?   25.07%
=========================================
  Files             ?       37
  Lines             ?     3143
  Branches          ?      604
=========================================
  Hits              ?      788
  Misses            ?     2330
  Partials          ?       25

Impacted Files
Coverage Δ

elliottlib/cli/list_cli.py
0.00% <0.00%> (ø)

elliottlib/gitdata.py
18.78% <0.00%> (ø)

elliottlib/logutil.py
80.00% <0.00%> (ø)

elliottlib/openshiftclient.py
0.00% <0.00%> (ø)

elliottlib/cli/tag_builds_cli.py
0.00% <0.00%> (ø)

elliottlib/cli/tarball_sources_cli.py
0.00% <0.00%> (ø)

elliottlib/runtime.py
18.39% <0.00%> (ø)

elliottlib/metadata.py
56.94% <0.00%> (ø)

elliottlib/cli/advisory_impetus_cli.py
0.00% <0.00%> (ø)

elliottlib/imagecfg.py
94.11% <0.00%> (ø)

... and 27 more

Continue to review full report at Codecov.

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


feat: add p2p URL support across all content in the reader

closes #17
Facing two issues:

Getting null src for img and video in the post content. The src attributes might be empty or not set at the time when the script tries to update them?

    const images = contentDOM.querySelectorAll('img')
    images.forEach(img => {
      const src = img.getAttribute('src')
      console.log('Original src:', src)
      img.setAttribute('src', resolveP2PUrl(src))
    })

    const videos = contentDOM.querySelectorAll('video source')
    videos.forEach(video => {
      const src = video.getAttribute('src')
      video.setAttribute('src', resolveP2PUrl(src))
    })

With the same updates in random sort timelines branch, getting this error:

For the searchNotes bit, check that you fixed the issues in #13 where the function got accidentally deleted

We shouldn't be resolving to gateways in browsers that support p2p urls. Instead see if there's a DOM event that gets emitted when an image/video fails to load and listen to it at the document.body then take the event.target and attempt to rewrite its src. Video takes also have different ways of specifying sets of sources so we should account for that too.

Yep, will add the fallback logic.
This approach is not working:
    // Setup error listeners for media elements within this component
    this.addEventListener('error', event => {
      const target = event.target;
      if (target.tagName === 'IMG' || (target.tagName === 'SOURCE' && target.parentElement.tagName === 'VIDEO')) {
        const originalSrc = target.getAttribute('src');
        if (!originalSrc.startsWith('hyper://') && !originalSrc.startsWith('ipns://')) {
          target.setAttribute('src', resolveP2PUrl(originalSrc));
        }
      }
    }, true);
  }

By resolving as null do you mean the originalSrc attribute is showing up as null or is the resolveP2PURL function returning null?

if (!originalSrc.startsWith('hyper://') && !originalSrc.startsWith('ipns://')) {
          target.setAttribute('src', resolveP2PUrl(originalSrc));
        }

This seems to only be trying to resolve the URL  if it isn't p2p. Should the if statement be resolved and have us try to update the src attribute right away?
Which browser are you testing this on? Which URL/post?

Mind committing your code?

Mind committing your code?

Fixed it!
Will commit in a few hours.

Mind committing your code?

Fixed it! Will commit in a few hours.

Resolving urls before rendering in loadAndRenderPost worked: https://github.com/hyphacoop/reader.distributed.press/pull/20/commits/675329fbd6051b2bb9d1b02200000842a771a962
Regarding the gateway fallback how is this approach in db.js?
export async function supportsP2P (url) {
  console.log(url)
  try {
    const response = await fetch(url)
    return response.ok
  } catch (error) {
    console.log('P2P URL loading failed:', error)
    return false
  }
}

export async function resolveP2PUrl (url) {
  if (!url) return url

  console.log('Attempting to resolve P2P URL:', url)

  if (isP2P(url)) {
    const p2pSupported = await supportsP2P(url)

    if (!p2pSupported) {
      if (url.startsWith(HYPER_PREFIX)) {
        return url.replace(HYPER_PREFIX, 'https://hyper.hypha.coop/hyper/')
      } else if (url.startsWith(IPNS_PREFIX)) {
        return url.replace(IPNS_PREFIX, 'https://ipfs.hypha.coop/ipns/')
      }
    }
  }

  return url
}

Can you elaborate on what the purpose of the proposed changes to db.js are?

Can you elaborate on what the purpose of the proposed changes to db.js are?

If the fetch fails, it will resolve the p2p URLs using gateways.

https://github.com/hyphacoop/reader.distributed.press/pull/20/commits/58366b88f0bbfa35b0515d5c904b71afc30e835f
The p2p-media.js is resolving to gateway if the fetch fails:

The problem is it's not replacing the src:
original img src:

p2p-image src:

We already have a fallback for detecting when p2p fetch fails: https://github.com/hyphacoop/reader.distributed.press/blob/main/db.js#L116 Lets stick to that without adding new stuff

p2p-image and p2p-video are working fine everywhere; the profile pictures in actor-profile, actor-profile-mini, and followed-accounts.
The media is not loading in the post content, I think there's something wrong with insertImagesAndVideos:
post.js:55 Updated p2p-image src after fallback: https://hyper.hypha.coop/hyper/hypha.coop/assets/images/posts/2022-05-12-ppl-sitting-unsplash.jpg
post.js:59 Replaced img with p2p-image having initial src: hyper://hypha.coop/assets/images/posts/2022-05-12-ppl-sitting-unsplash.jpg

I'm currently debugging the issue.

We should modify the supportsP2P function so it only checks for the p2p schemes once.
something like this

have a global map of <protocol promise<boolean> | boolean>
supports will get the scheme from the src
check if the map has a value for the scheme if(supportMap.has(scheme)) return await supportMap.get(scheme)
if doesn't have, set a promise for attempting to resolve the url scheme
if request fails on a network error (no http response) set it to false and return false
else set to true

This will reduce the number of http requests and improve performance.

https://github.com/hyphacoop/reader.distributed.press/blob/b5f63705addda30211318df4daf1988e66882aa7/db.js#L48

@akhileshthite have you been able to apply th changes requested here?

@akhileshthite have you been able to apply th changes requested here?

On it
Thanks

Now we can load the p2p content in non p2p browsers :)


Remove PathfindtoPosition and replace it with MoveToPosition

./ai/STA/Action/PathfindToPosition.py:10:# TODO remove this and use MoveToPosition (Simon B)

The problem: This code is obsolete, it should be replaced everywhere with MoveToPosition.

This class is already getting delete


[H001045] Rep. Gregg Harper

Rep. Gregg Harper:
http://harper.house.gov
Likely contact form URL to start with:
http://harper.house.gov/contact-gregg

YMAL file not found. I am working on it.


Quick questions about Remhos mini app

Hi all,
As far as I understand the concept behind Remhos, this mini app is designed to interpolate an L2 quantity from an old mesh to a new mesh by solving advection. It sounds a degree of similar to the particle tracking method to me.
To accomplish this, we require velocity information, which is essentially the displacement between the old and new meshes, as it manages the fictitious time interval ranging from 0 to 1.
I've been thinking about what happens when the new mesh, generated by TMOP, undergoes significant deformation compared to the old one.
Examples of Remhos applications, such as Taylor-Green deformation used for mesh motion, demonstrate nearly perfect remapping. This success is attributed to Remhos utilizing time discretization within the interval from 0 to 1 and sub-velocity information for each time step, I think.
However, what if we have a scenario with only constant displacement (velocity) because we don't know the path history between the old and new meshes, is several-time discretization still essential?
Can we handle significant mesh displacement (velocity) without the need for variable sub-velocity information?
Best,
Sungho

Hi @sungho91,
The velocity in Remhos is always constant (in time). So you're correct, large displacements might be problematic.

Hi @vladotomov,
Thank you for commenting. I was just wondering because I am working on implementing Remhos into my code.
But it is still great because its theoretical background sounds strong.
Yes, I'll use Rmehos Github issue page. I just had a bit of concern about not much strong activity of Remhos.


Github Pages documentation does not detail step for changing master to main

What article on docs.github.com is affected?
https://docs.github.com/en/free-pro-team@latest/github/working-with-github-pages/creating-a-github-pages-site
What part(s) of the article would you like to see updated?
As documented here, github pages can be now be deployed from any branch. However, when making a google pages site today, I encountered a situation that can use clarifying.

The repo defaults to deploying from master, at least on my end. Since the default name is now "main" instead of "master", if these instructions are followed by a newer user, they will likely spend time troubleshooting why their website doesn't appear.
A step added to the section in the image below would clarify this for users and help in troubleshooting should their page not be available when following these instructions.

Additional information
N/A

👋 @ironandstee1 Thanks for opening an issue!
I'm not seeing anything in that particular article about choosing a branch to deploy your GitHub Pages site from, so I don't think there was much updated there around default branches. In the "Creating your site" section, there's a link in step 5 to the "Configuring a publishing source for your GitHub Pages site" article. Do you think that article clarifies the new options to publish from any branch?

I didn't get an answer to this question and it's not in a state where we can take action right now. So I'm going to close this. If you have any other docs needs, let us know!


Fixed an error in the size description of the icon

The Table that show the size difference between the Flickr icons are different in the Size Comparison table and the Social Media table.
I just changed the the size from 251 to 250 as is says in the social media table and what the Windows file system reports.

Good spot! Thanks :-)


[Doc] Video formats (video_frames and video_keyframes)

Summary

How to test

Checklist

[ ] I have added unit tests to cover my changes.
[ ] I have added integration tests to cover my changes.
[ ] I have added the description of my changes into CHANGELOG.
[ ] I have updated the documentation accordingly

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below)

# Copyright (C) 2023 Intel Corporation
#
# SPDX-License-Identifier: MIT

Codecov Report
Patch coverage has no change and project coverage change: -0.01 :warning:

Comparison is base (e601f3e) 78.49% compared to head (4005354) 78.49%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #871      +/-   ##
===========================================
- Coverage    78.49%   78.49%   -0.01%
===========================================
  Files          206      206
  Lines        24939    24939
  Branches      5007     5007
===========================================
- Hits         19577    19575       -2
- Misses        4236     4237       +1
- Partials      1126     1127       +1

Flag
Coverage Δ

macos-11_Python-3.8
?

ubuntu-20.04_Python-3.8
78.49% <ø> (ø)

windows-2019_Python-3.8
?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Ugly font and overlapping close tab on text

Hello,
Please, take a look on screenshot, you will see problem:
http://i.piccy.info/i9/ad696a508bff2bdb5bdfceeb944b25f2/1468215440/5940/1050747/atom_180_ugly_icons.png
I'm using Atom 1.8.0 under windows 8.1

Closing as duplicate of https://github.com/atom/one-light-ui/issues/59, and will be fixed in an upcoming relase of Atom.


qtwebengine requires 32 bit host environment

When trying to build qtwebengine on a 64 bit system for ARM, bitbake fails with
| ...hosttools/g++ ...  -m32 -msse2 -mfpmath=sse -mmmx -o v8_snapshot/obj/third_party/icu/bundled_icui18n/decContext.o
| In file included from /usr/include/features.h:452,
|                  from /usr/include/bits/libc-header-start.h:33,
|                  from /usr/include/string.h:26,
|                  from ../../../../git/src/3rdparty/chromium/third_party/icu/source/i18n/decContext.cpp:25:
| /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory
|  # include <gnu/stubs-32.h>

src/buildtools/configure_host.pro causes the 64 to 32 bit "downgrade" by
contains(GN_TARGET_CPU, "arm")|contains(GN_TARGET_CPU, "mipsel")|contains(GN_TARGET_CPU, "x86") {
    # The v8 snapshot need a host that matches bitwidth, so we build makesnapshot to 32-bit variants of host.
    contains(GN_V8_HOST_CPU, x64): GN_V8_HOST_CPU = "x86"

Seen in "thud" branch; rev 201fcf27cf07d60b7d6ab89c7dcefe2190217745

On CentOS 7, you need to install the package glibc-devel.i686.
 yum install glibc-devel.i686

That will install the missing header file. Other distros have similar packages, like libc-dev:i386 in Debian.

FWIW: on master you need glibc-static either (think 32Bit - installed both 32/64 so I don't know). Maybe it is worth dropping a note in the recipe?

Just had it a my home PC and I was wrong: it is not glib but libsstdc++-static which is required
| /home/superandy/tmp/oe-core-glibc/hosttools/ld: cannot find -lstdc++

I think this is a really bad situation and violates the self-hosting idea behind OpenEmbedded.  Perhaps this code can be compiled for the target and executed with qemu?

It's like this since 5.9 upgrade, see:
https://github.com/meta-qt5/meta-qt5/commit/969f1f80bf255498abbec6886d443670c20a79c8
I don't like it at all, see:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-August/114417.html
and similar discussions from that time, but in the end I gave up, if Qt isn't going to ever fix it, I don't want to carry another not-upstream-able patch in meta-qt5 (there are too many already).
Please send README update.


buildFromComponent could accept a vnode-object and wrap it in a function...?

Disclaimer: Almost newbie!
Just started testing Cycle.js, and following the JSX  docs there, it annoyes me that I have to manually wrap the virtual nodes with functions to make them act as tag-components.
Could buildFromComponent just accept vnodes and wrap instead of throwing?
Cheers.

I use Cycle as well, but I'm not sure I understand how you are trying to use components in JSX. Do you have an example repo you can point to of what you are trying to accomplish?

Something related to my unfinished noodling about #18, maybe?

Perhaps, I am not quite sure what you mean by thunks, but as a contrived example with snippets from the cycle.js documentation:
Given the LabeledSlider.js component, I'd like to use it in BmiCalculator.js as a "React component in pure jsx".
import LabeledSlider from './LabeledSlider'
/* ... */
const weightSlider = isolate(LabeledSlider)({DOM: domSource$, props: weightProps$});
const heightSlider = isolate(LabeledSlider)({DOM: domSource$, props: heightProps$});
/* ... */
const vdom$ = xs.combine(state$, weightVDom$, heightVDom$)
    .map(([state, weightVDom, heightVDom]) => {
      // THIS `map` could be done automagically:
      return [state, () => weightVDom, () => heightVDom]
    })
    .map(([state, WeightSlider, HeightSlider]) =>

        <WeightSlider /> //
        <HeightSlider />

{state.label} BMI is {state.bmi}

    );

Now I just need another .map to wrap the VDoms in a function, or fake anything that buildFromComponent accepts. So can buildFromComponent accept a pure VDom object and wrap it, is what I am asking.
...and, looking at it again now, yes it's a thunk =)
Cheers!

That does give me a better perspective of what you are looking for. The components I've built actually use the arguments to the component function for data passing and complex low-level Snabbdom stuff. An abbreviated example:
export function Graph({ data, layout }: any, children: any) {
    return

}

const exampleGraph = (state: any) => <Graph data={ state.dataSource } layout={ state.layoutInfo } />

In cases like your example I wouldn't be using JSX components and would just write it as:
import LabeledSlider from './LabeledSlider'
/* ... */
const weightSlider = isolate(LabeledSlider)({DOM: domSource$, props: weightProps$});
const heightSlider = isolate(LabeledSlider)({DOM: domSource$, props: heightProps$});
/* ... */
const vdom$ = xs.combine(state$, weightVDom$, heightVDom$)
    .map(([state, weightSlider, heightSlider]) =>

        { weightSlider } //
        { heightSlider }

{state.label} BMI is {state.bmi}

    );

(Thunks are snabbdom boundaries to keep from patching the contents as often by passing it a bit more state information that it checks for equality first. Cycle isolate sort-of auto-thunks. I could use auto-thunking for things like my Graph component.)

Hmm...
Your last example is identical to the cycle.js documentation-example. For me the difference seems to be just the semantics of e.g { weightSlider } vs <WeightSlider />.
-So, are you saying is that there is a higher cost to using <Component />s due to vdom-diffing because the component is not assumed "pre-rendered" and static in the context, whereas a vdom object is?
Snabbdom is not a cycle.js exclusive, but sine that is my learning approach, I might be blindsided by that context.
Thanks.

Sure, let's take a step back, ignore thunks as a low level detail and look at the overall philosophy. JSX components come from the React world. React components (despite or in spite of the name "React") follow a pull-model. It's up to a component to pull the information it needs. When a React JSX file use a <Component /> it is doing everything necessary to setup/teardown that component and start that component's data pull.
CycleJS takes a much more push model: components "request" data from drivers and drivers push data as it becomes available. To wire in a new component you have to consider where its inputs should come from and where its outputs should go, in your consuming component's intent/model somewhere. By the time it gets to assembling that all into your components view, almost all of the work has already been done, almost all of the data has already arrived, you just plug it into the right holes in you view template and move on.
It might be better is CycleJS used a different name than "component" to differentiate the difference between what React is doing with its "component" model, they act quite differently.
Where I use JSX components in my Cycle app is for things like HTML macros/templates where I want to slot some other tags inside it somewhere (children) (and even then there's still a likelihood I may just use { templateViewFunction(attrs,
child
) } directly unless it starts to get ugly/complicated looking), or things that have DOM "side effects" that I need to use snabbdom hooks to manage like setup/teardown of a graphing library, Leaflet map, or URL.createObjectURL(blob) and URL.revokeObjectURL(blob) management for building image src URLs from database Blobs.
{ weightSlider } is just a value at the point where that view is getting it. It doesn't have any more work to be done, nor any more side-effects that need to happen to the DOM. Other than aesthetics, is there a benefit you can see to being able to use the <WeightSlider /> syntax? You can't give it attributes, because those should already be passed in the weightProps$ observable; same with children. You can't really take advantage of the tag structure <WeightSlider prop1="example">Inside the slider</WeightSlider>. You would also be signaling to me, from my project experience, that <WeightSlider /> may have snabbdom/DOM side effects when that isn't the case.
(Though this does give me thoughts about you could build a JsxDriver for Cycle that could take advantage of those things, and maybe replace weightProps$ with the source from that driver. I'm not sure useful that would be, though... and so far in the direction of most Cycle development wouldn't feel all that appropriate.)

Excellent!
cycle.js uses the term dataflow component, so I guess that is an attempt at differentiation while still keeping in touch with the component-buzz.
Other than that, I see what you mean now (although it will take me a fair bit of practice to grok it properly).
So thank you for the clarifications, really warms my heart that you took the time to write it out.
Feel free to close the issue.

Glad I could help.


config: fix disabling config 'Debug'

Currently, disabling the config property Debug
(cilium-dbg config Debug=disable) doesn't change the log level of the Cilium Agent (and proxies) back to the default log level. The log level stays at debug.
The reason is that #16021 changed the logging API from accepting the loglevel to explicit methods to enable debug level or reset it to the defaut log level. Hence it no longer supports toggling the log level.
This commit fixes this by explicitly reset the log level of the default logger by calling logging.SetDefaultLogLevel() if the config option Debug is disabled.

/test

Should we backport this PR? I guess it would qualify as debug improvement under the backporting criteria: https://docs.cilium.io/en/stable/contributing/release/backports/#backport-criteria-for-x-y-1-z-and-x-y-2-z

Should we backport this PR? I guess it would qualify as debug improvement under the backporting criteria: https://docs.cilium.io/en/stable/contributing/release/backports/#backport-criteria-for-x-y-1-z-and-x-y-2-z

Probably yes. Even though i have to make the backports manually as the config rest api handler has been moved lately into the rest api cell with https://github.com/cilium/cilium/pull/33116.


feat (Analysis.SpecificLimits.Basic): add lemma tendsto_pow_atTop_nhds_0_iff_lt_1

Add lemma tendsto_pow_atTop_nhds_0_iff_lt_1 showing the reverse implication of tendsto_pow_atTop_nhds_0_of_lt_1: if the geometric progression of an element in an Archimedean field tends to 0, the element is strictly less than 1.

(Note: in mathlib4, we don't write the filename in the PR title anymore.)

I hope I have implemented all the suggestions.


Very awesome and interactive read!

Just wanted to say thank you for constructing this well made readme!

@oshalom-dcg appreciate your feedback, I'm happy that you like it. I hope to add more information once I get time.


After CopySource LND is locked

When a RaspiBlitz was in CopySource Mode for another RaspiBlitz and is done LND is still unlocked while the Blitz itself is showing the main menu.

fixed & tested


oni2 consistently locks up when opening a file in a specific private repository

I can consistently reproduce only locking up an using 100 CPU.
Steps to reproduce:

opening oni2 in said repo
using ctrl-p to open a file (a github actions yaml file)
editor locks up, UI does not refresh anymore and CPU consumption goes to 100% for the main process.

I'm happy to provide some trace to figure out what it's doing, just not sure what to use. Can somebody point to towards a preferred tool (perf, ftrace?)?
Logs: https://gist.github.com/despairblue/df04cc18554a4eda8439245d6809fe98

Thanks for the testing / great bugs you've logged @despairblue - really appreciate it!
At first - based on the description and repro, I thought that it might be another font fallback issue (https://github.com/revery-ui/revery/pull/989 https://github.com/revery-ui/revery/pull/980 https://github.com/revery-ui/revery/pull/974) . But based on the log, that doesn't seem to be the case - it's pretty clear in the log when that occurs, since it spins on a particular character.
In your log - seems to be hanging right after opening a buffer:
[DEBUG]    +0ms Oni2.Store.dispatch : After: (Buffers
   Entered {id = 3; fileType = (Buffer.FileType.Inferred "yaml");
     lineEndings = <opaque>;
     filePath =
     (Some "master.yml");
     isModified = false; version = 0;
     font =
     { fontFamily = <opaque>; fontSize = 14.; spaceWidth = 8.39996337891;
       underscoreWidth = 8.39996337891; avgCharWidth = 8.4000005722;
       maxCharWidth = 33.8100013733; measuredHeight = 17.3600006104;
       descenderHeight = 3.78000020981; smoothing = <opaque>;
       features = <opaque> };
     buffer = <opaque>})
[DEBUG]    +0ms Oni2.Store.Vim : Buffer update: 3

I'm happy to provide some trace to figure out what it's doing, just not sure what to use. Can somebody point to towards a preferred tool (perf, ftrace?)?

This would definitely be helpful, thanks @despairblue !
You could do the following to get a call-stack:

Run Onivim 2 via esy run -f
Run ps -a | grep Oni2_editor to get a list of editor processes. There should be two (one is the UI, one is the syntax service)
Reproduce the hang
Note the PID of both processes, and for each of them, run: gdb -batch -ex -bt -p <pid>

Would be interesting to see what the callstacks for each of the processes are - might give us a clear.
My hunch would be either something hanging in syntax highlighting, or perhaps some blocking state is being triggered in Vim on opening the file.
Another option, if you're up for it, would be to 'binary search' - try removing half of the file, open Onivim, see if it occurs, etc - until we can narrow it down to a particular line in the yaml file.
A few other thoughts:

Which YAML extension are you using?
Do you have experimental viml configured in your configuration?

I downloaded a couple yaml extensions (the vscode code one, and redhat one) and tried opening this file in different environments: https://github.com/revery-ui/revery/blob/master/.github/workflows/validate-pr.yml but no luck in reproducing (it opened successfully)

@bryphe sorry for the long wait.

Which YAML extension are you using?

I'm using<EMAIL_ADDRESS>
Do you have experimental viml configured in your configuration?

Nope
I did the binary search as well. The problem happens when Oni2 needs to render number emojis: 1⃣ and 2⃣
Other emojis it renders just fine (like  ♻  🚨  🚧  or  🏁 )
Call Stacks

Process 1
[New LWP 411735]
[New LWP 411736]
[New LWP 411737]
[New LWP 411738]
[New LWP 411748]
[New LWP 411769]
[New LWP 411770]
[New LWP 411771]
[New LWP 411772]
[New LWP 411773]
[New LWP 411778]
[New LWP 411779]
[New LWP 411780]
[New LWP 411781]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
mark_slice_darken (slice_pointers=<synthetic pointer>, in_ephemeron=0, i=<optimized out>, v=94800906159032, gray_vals_ptr=0x563898b3d418) at major_gc.c:258
258	    if (Tag_hd (chd) == Forward_tag){
#0  mark_slice_darken (slice_pointers=<synthetic pointer>, in_ephemeron=0, i=<optimized out>, v=94800906159032, gray_vals_ptr=0x563898b3d418) at major_gc.c:258
#1  mark_slice (work=95787) at major_gc.c:420
#2  0x000056388ad53515 in caml_major_collection_slice (howmuch=howmuch@entry=-1) at major_gc.c:792
#3  0x000056388ad546b9 in caml_gc_dispatch () at minor_gc.c:473
#4  0x000056388ad4fc39 in caml_garbage_collection () at signals_nat.c:85
#5  0x000056388ad6deaa in caml_call_gc ()
#6  0x0000000000000000 in  ()
[Inferior 1 (process 411732) detached]

Process 2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f5ff888759a in epoll_wait () from /usr/lib/libc.so.6
#0  0x00007f5ff888759a in epoll_wait () at /usr/lib/libc.so.6
#1  0x000055d358c98f9d in uv__io_poll (loop=loop@entry=0x55d3595e4bc0 <default_loop_struct>, timeout=5000) at src/unix/linux-core.c:307
#2  0x000055d358c89f24 in uv_run (loop=loop@entry=0x55d3595e4bc0 <default_loop_struct>, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:385
#3  0x000055d358c7fa16 in luv_stub_blocking_1_uv_run (x1312=<optimized out>, x1311=<optimized out>) at c_generated_functions.c:1732
#4  0x000055d35834e26a in camlLuv_c_generated_functions__fun_6183 () at src/unix/core.c:846
#5  0x00007f5ff7b743b8 in  ()
#6  0x000055d357f7e984 in camlOni_Syntax_Server__start_185 () at src/unix/core.c:846
#7  0x00000000000c90a9 in  ()
#8  0x000055d358f4dbb0 in camlOni2_editor__151 ()
#9  0x00007f5ff7b74f48 in  ()
#10 0x00007f5ff7b74f28 in  ()
#11 0x00007f5ff7b74f08 in  ()
#12 0x00007f5ff7b74de8 in  ()
#13 0x00007f5ff7b74c38 in  ()
#14 0x00007f5ff7b74c10 in  ()
#15 0x00007f5ff7b75148 in  ()
#16 0x00007f5ff7b74f68 in  ()
#17 0x00007f5ff7b75c98 in  ()
#18 0x000055d357f77b2b in camlOni2_editor__entry () at src/unix/core.c:846
#19 0x00000000000002d0 in  ()
#20 0x000055d357f78ba6 in camlHealthCheck__entry () at src/unix/core.c:846
#21 0x00007f5ff7b7b718 in  ()
#22 0x000055d357f691f9 in caml_program () at src/unix/core.c:846
#23 0x0000000000000001 in  ()
#24 0x000055d358cca0b4 in caml_start_program ()
#25 0x0000000000000000 in  ()
[Inferior 1 (process 411759) detached]

Hi @despairblue ,
I've been trying to reproduce this - I created a minimal YAML file with those emojis, and haven't been able to reproduce the hang / crash.
I'm wondering if you happen to have the file around that you used for binary-searching?
It may be the same hang that was addressed in this Revery fix https://github.com/revery-ui/revery/commit/18eb60e6d5b99adebcf5912d05c447e83a0f7e0b , which is now in Onivim - so perhaps it no longer reproduces :crossed_fingers:

@bryphe thanks for checking it out. I tried it again and yes it does not crash anymore :clap:
Now it does not render emojis anymore at all:

Same file, left is atom and right is oni.
I'm fine with that, better than crashing. Should I open another issue though?

Thanks @despairblue for checking!

I'm fine with that, better than crashing. Should I open another issue though?

Sure, another issue would be great  - if you could attach the file ,that would be helpful.  Would also be curious what version of harfbuzz is installed on your system - can check with the :version command:

Also noticed a weird bug with the indent renderer being drawn in the wrong place:

...looking at a fix for that.

@bryphe I opened a new one :)
#2775