Error starting docker from Frontend Repo

@lazyguru So the fix you pushed last night definitely fixed the original error I was receiving, however now the startup progresses much further but is still failing with the federation container in an unhealthy state:
seeder-1      | Running likePost() for entity with ID 10
api-1         | 2024-06-09T23:03:30.913Z DEBUG 1 --- [nio-8080-exec-8] o.s.web.servlet.DispatcherServlet        : POST "/api/v3/user/login", parameters={}
api-1         | 2024-06-09T23:03:30.913Z DEBUG 1 --- [nio-8080-exec-8] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped to com.sublinks.sublinksapi.api.lemmy.v3.user.controllers.UserAuthController#login(HttpServletRequest, Login)
api-1         | 2024-06-09T23:03:30.914Z DEBUG 1 --- [nio-8080-exec-8] m.m.a.RequestResponseBodyMethodProcessor : Read "application/json;charset=UTF-8" to [Login[username_or_email=luke, password=password123, totp_2fa_token=null]]
Gracefully stopping... (press Ctrl+C again to force)
dependency failed to start: container docker-federation-1 is unhealthy

Oh.... I found the problem.
@devanbenz the StartConsumer function is synchronis (it's not returning until the queue is stopped). So only the actors queue is running. We aren't processing other messages and also not getting to the point where the http service is started.

@chasingtheflow can you confirm it is working for you now? (I was able to get to the point at which the UI fails to startup, but I think this is because I didn't run npm run dev)

Now I'm getting the following:
federation-1  | {"level":"fatal","error":"dial tcp <IP_ADDRESS>:5672: connect: connection refused","message":"failed connecting to queue service"}
federation-1  | {"level":"debug","message":"main logger started"}
federation-1  | {"level":"warn","message":"failed to load env, open .env: no such file or directory"}
federation-1  | {"level":"debug","message":"db migrations logger started"}
federation-1  | {"level":"debug","message":"Running migrations..."}
federation-1  | {"level":"debug","message":"Done!"}
federation-1  | {"level":"fatal","error":"dial tcp <IP_ADDRESS>:5672: connect: connection refused","message":"failed connecting to queue service"}
ui-1          |  ○ Compiling / ...
api-1         | 2024-06-10T04:02:35.255Z  INFO 1 --- [           main] o.h.e.t.j.p.i.JtaPlatformInitiator       : HHH000489: No JTA platform available (set 'hibernate.transaction.jta.platform' to enable JTA platform integration)
api-1         | 2024-06-10T04:02:35.263Z  INFO 1 --- [           main] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
dependency failed to start: container docker-federation-1 is unhealthy
➜  frontend git:(issue/62) ✗

Make sure you have done the following:
docker compose -f docker/docker-compose.frontend.yml down
docker compose -f docker/docker-compose.frontend.yml pull
docker compose -f docker/docker-compose.frontend.yml up

Actually, just kidding. I ran into a privileged port issue for port 443 which I worked around and then I ran:
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

then docker compose -f docker/docker-compose.frontend.yml pull
and it took a long time on a raspberry pi 5 but it did run and am able to see / work with the frontend. Thanks for your help!

No worries. Glad it is working now


AdminNavBar will no longer expand

Admin Nar Bar will no longer expand when there's enough space and the button remains.

congrats!


cargo build fails due to lack of wasm target

error: couldn't read [snip]/target/service/[crate-name].wasm: No such file or directory (os error 2)
--> src/lib.rs: 3:1
3 | #[oasis_std::service]

error: aborting due to previous error

wasm-build is going to be replaced by oasis-build


Workaround/bids validator

Hi,
Another member of my lab was interested in using this utility, but we kept on getting stuck with the bids-validator getting an error like this
<--- Last few GCs --->

  426429 ms: Scavenge 1402.9 (1457.3) -> 1402.9 (1457.3) MB, 3.8 / 0 ms (+ 1.3 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
  427370 ms: Mark-sweep 1402.9 (1457.3) -> 1401.6 (1457.3) MB, 940.5 / 0 ms (+ 1.3 ms in 1 steps since start of marking, biggest step 1.3 ms) [last resort gc].
  428305 ms: Mark-sweep 1401.6 (1457.3) -> 1401.6 (1457.3) MB, 935.2 / 0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x2990767b4629 <JS Object>
    2: getFiles(aka getFiles) [/usr/local/lib/node_modules/bids-validator/utils/files.js:~97] [pc=0x178a22475a7e] (this=0x2990767041b9 <undefined>,dir=0x1898105ee731 <String[107]: /home/jdkent/mnt/vosslabhpc/Projects/Bike_ATrain/Imaging/BIDS/sourcedata/RAW_BIDS/sub-GEP385/ses-passivepre>,files_=0x1226ebeb1379 <JS Array[4918904]>)
    3: getFiles(aka getFiles) [/usr/local/lib/node_modules/bids-v...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Aborted (core dumped)

I played with the --config option for bids-validator with no avail, and for the interest of time, I provided this workaround to make the container run. I think the error is related to bids-validator trying to read into sourcedata and derivatives, but I couldn't get the --config option to work for me.
P.S.
I also did some flake8 conforming with the code so that is more in line with PEP 8 standards.
best,
James

sorry, I should have included versions, it's happening with the versions installed in the docker container, and with version bids-validator: 0.23.11; node: v4.2.6 when I try it as it's installed on my computer (Ubuntu 16.04). I have not tried with branch  INCF/bids-validator#346, I will try that next.

Might be also worth updating node.js

I repeated the process with node: v6.11.5, but got a similar result:
bids-validator --config bids-validator.config ~/mnt/vosslabhpc/Projects/Bike_ATrain/Imaging/BIDS

<--- Last few GCs --->

  384744 ms: Mark-sweep 1377.8 (1437.8) -> 1377.8 (1437.8) MB, 1287.2 / 0.0 ms [allocation failure] [GC in old space requested].
  385984 ms: Mark-sweep 1377.8 (1437.8) -> 1377.8 (1437.8) MB, 1240.0 / 0.0 ms [allocation failure] [GC in old space requested].
  387265 ms: Mark-sweep 1377.8 (1437.8) -> 1377.8 (1417.8) MB, 1280.3 / 0.0 ms [last resort gc].
  388510 ms: Mark-sweep 1377.8 (1417.8) -> 1377.8 (1417.8) MB, 1245.1 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x2623298cf781 <JS Object>
    2: getFiles [/usr/local/lib/node_modules/bids-validator/utils/files.js:102] [pc=0x2673977873f] (this=0x8a8b9d8db29 <JS Global Object>,dir=0x35537f496249 <String[168]: /home/jdkent/mnt/vosslabhpc/Projects/Bike_ATrain/Imaging/BIDS/sourcedata/RAW_BIDS/sub-GEP385/ses-activepost/func/sub-GEP385_ses-activepost_task-spatialnback_run-01_bold>,files_=0x1b7c942e5369 <JS Array[4861460]>)
    3: getFil...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [bids-validator]
 2: 0x109f13c [bids-validator]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [bids-validator]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [bids-validator]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [bids-validator]
 6: v8::internal::Factory::NewScopeInfo(int) [bids-validator]
 7: v8::internal::ScopeInfo::Create(v8::internal::Isolate*, v8::internal::Zone*, v8::internal::Scope*) [bids-validator]
 8: 0xb4f7b3 [bids-validator]
 9: 0xb56e46 [bids-validator]
10: v8::internal::Compiler::Compile(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Compiler::ClearExceptionFlag) [bids-validator]
11: v8::internal::Runtime_CompileLazy(int, v8::internal::Object**, v8::internal::Isolate*) [bids-validator]
12: 0x267394092a7
Aborted (core dumped)

bids-validator still appears to be traversing the sourcedata directory despite me trying to tell it not to.
I've tried this with the config file either containing this:
{
	"ignoredFiles": ["derivatives/**", "sourcedata/**"]
}

or this:
{
	"ignoredFiles": ["/derivatives/**", "/sourcedata/**"]
}

So then my next step should be using the new branch? or am I not specifying the config file correctly?
Should we move this conversation to the bids-validator github?

That branch should help with avoiding traversing unwanted files. Please
give it a try.
Best,
Chris
On Wed, Nov 1, 2017 at 10:15 PM, James Kent<EMAIL_ADDRESS>wrote:

I repeated the process with node: v6.11.5, but got a similar result:
bids-validator --config bids-validator.config ~/mnt/vosslabhpc/Projects/Bike_ATrain/Imaging/BIDS
<--- Last few GCs --->
384744 ms: Mark-sweep 1377.8 (1437.8) -> 1377.8 (1437.8) MB, 1287.2 / 0.0 ms [allocation failure] [GC in old space requested].
385984 ms: Mark-sweep 1377.8 (1437.8) -> 1377.8 (1437.8) MB, 1240.0 / 0.0 ms [allocation failure] [GC in old space requested].
387265 ms: Mark-sweep 1377.8 (1437.8) -> 1377.8 (1417.8) MB, 1280.3 / 0.0 ms [last resort gc].
388510 ms: Mark-sweep 1377.8 (1417.8) -> 1377.8 (1417.8) MB, 1245.1 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x2623298cf781
2: getFiles [/usr/local/lib/node_modules/bids-validator/utils/files.js:102] [pc=0x2673977873f] (this=0x8a8b9d8db29 ,dir=0x35537f496249 <String[168]: /home/jdkent/mnt/vosslabhpc/Projects/Bike_ATrain/Imaging/BIDS/sourcedata/RAW_BIDS/sub-GEP385/ses-activepost/func/sub-GEP385_ses-activepost_task-spatialnback_run-01_bold>,files_=0x1b7c942e5369 <JS Array[4861460]>)
3: getFil...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [bids-validator]
2: 0x109f13c [bids-validator]
3: v8::Utils::ReportApiFailure(char const*, char const*) [bids-validator]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [bids-validator]
5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [bids-validator]
6: v8::internal::Factory::NewScopeInfo(int) [bids-validator]
7: v8::internal::ScopeInfo::Create(v8::internal::Isolate*, v8::internal::Zone*, v8::internal::Scope*) [bids-validator]
8: 0xb4f7b3 [bids-validator]
9: 0xb56e46 [bids-validator]
10: v8::internal::Compiler::Compile(v8::internal::Handlev8::internal::JSFunction, v8::internal::Compiler::ClearExceptionFlag) [bids-validator]
11: v8::internal::Runtime_CompileLazy(int, v8::internal::Object**, v8::internal::Isolate*) [bids-validator]
12: 0x267394092a7
Aborted (core dumped)
bids-validator still appears to be traversing the sourcedata directory
despite me trying to tell it not to.
I've tried this with the config file either containing this:
{
"ignoredFiles": ["derivatives/", "sourcedata/"]
}
or this:
{
"ignoredFiles": ["/derivatives/", "/sourcedata/"]
}
So then my next step should be using the new branch? or am I not
specifying the config file correctly?
Should we move this conversation to the bids-validator github?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/BIDS-Apps/freesurfer/pull/37#issuecomment-341320023,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOkp_NzvHbax4G6h054BoiI279qtjN4ks5syVAOgaJpZM4QO3W2
.

installed the branch like so:
npm install -g https://github.com/suyashdb/bids-validator.git#optimizeTraversalOfDirectory
and that version worked perfectly, thanks!
Should we still include this pull request to allow users the option to not do a bids-check (if they have already done this themselves) of if they want to use a specific configuration of bids-validator?

Thanks!


Exam mode: Allow editing individual working time during conduction

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[x] I chose a title conforming to the naming conventions for pull requests.

Server

[x] I followed the coding and design guidelines.
[x] I added multiple integration tests (Spring) related to the features (with a high test coverage).
[x] I implemented the changes with a good performance and prevented too many database calls.
[x] I documented the Java code using JavaDoc style.

Client

[x] I followed the coding and design guidelines and ensured that the layout is responsive.
[x] I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
[x] I documented the TypeScript code using JSDoc style.
[x] I translated all newly inserted strings into English and German.

Changes affecting Programming Exercises

[x] I tested all changes and their related features with all corresponding user types on Test Server 1 (Atlassian Suite).
[x] I tested all changes and their related features with all corresponding user types on Test Server 2 (Jenkins and Gitlab).

Motivation and Context

#5962
Description

It is now possible to change the working time of individual student exams during their conduction. The change is also sent via web socket to the student and displayed as an alert at the top right of the screen.
Programming exercises should get locked at the new due date for the student.
Steps for Testing

Prerequisites:

1 Instructor
2 Students
1 Exam with a programming exercise.

Log in to Artemis
Create the exam
Participate as both students (you can do this simultaneously)
Go to the student exam overview as instructor
Decrease the working time of one student and verify that the student gets a notification (e.g. use two browsers one for the student, one for the instructor)
Increase the working time of the other student and verify that the student gets a notification (e.g. use two browsers one for the student, one for the instructor)
Make surre that both repositories are locked at their respective due date and the student can no longer push

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Codecov Report

Merging #6085 (1c93b5a) into develop (2cd54c2) will decrease coverage by 0.00%.
The diff coverage is 73.46%.

Additional details and impacted files
@@              Coverage Diff              @@
##             develop    #6085      +/-   ##
=============================================
- Coverage      80.07%   80.07%   -0.01%
- Complexity     12693    12701       +8
=============================================
  Files           2192     2192
  Lines          86883    86914      +31
  Branches       12980    12983       +3
=============================================
+ Hits           69575    69598      +23
- Misses          9610     9614       +4
- Partials        7698     7702       +4

Impacted Files
Coverage Δ

...ssaging/DistributedInstanceMessageSendService.java
7.24% <0.00%> (-0.33%)
:arrow_down:

...age/student-exams/student-exam-detail.component.ts
77.88% <0.00%> (+1.09%)
:arrow_up:

.../scheduled/ProgrammingExerciseScheduleService.java
79.19% <71.42%> (-0.66%)
:arrow_down:

.../in/www1/artemis/web/rest/StudentExamResource.java
86.60% <80.00%> (+0.06%)
:arrow_up:

...p/exam/participate/exam-participation.component.ts
66.47% <82.35%> (+1.02%)
:arrow_up:

.../www1/artemis/service/exam/StudentExamService.java
84.28% <100.00%> (+0.11%)
:arrow_up:

...rvice/messaging/InstanceMessageReceiveService.java
61.76% <100.00%> (+0.68%)
:arrow_up:

...vice/messaging/MainInstanceMessageSendService.java
95.34% <100.00%> (+0.22%)
:arrow_up:

...n/www1/artemis/service/messaging/MessageTopic.java
100.00% <100.00%> (ø)

...e/scheduled/WeeklyEmailSummaryScheduleService.java
65.51% <0.00%> (-3.45%)
:arrow_down:

... and 1 more

Flag
Coverage Δ

client
76.06% <73.68%> (+<0.01%)
:arrow_up:

server
84.54% <73.33%> (-0.02%)
:arrow_down:

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 2cd54c2...1c93b5a. Read the comment docs.


Fixed asan issue for test_AIO when an argument wasn't set on the command line

Cherry-picked to v10.0.x


Support for new style document icon for macOS Bug Sur

macOS Big Sur has been using a new way to define document icons with center image, background fill and text.

Adopting this kind of document icon can help making icons more consistent with those defined in system as well as other apps adopting this style.

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!


Update to Akka.Persistence <IP_ADDRESS>

The new PipeTo was breaking this plugin.

@trbngr ugh, really? - can you explain?

still have a minor test failure here - going to try re-running it

Method resolution was failing with MethodNotFoundException.
All test pass on my machine. I think xunit2 has problems with running too many ActorSystems in parallel. In my project, for example, I have to run it with -maxthreads 2

Welp. That won't help us here. I just noticed that all parallelism is turned off in the test runner. :(

Also you'll notice that each build will fail on different tests. I have a huge problem with this in my project too. If you know of any workarounds, I'm all ears.

@trbngr going to merge it and release it for now so it solves your immediate problem. I'll bring my "death to async / await" campaign to this repo soon enough and get to the bottom of these issues

Thanks, dude.


AsterNet Login Authentication Fail [need help]

I am new to AsterNET. Hope can get some help here:
The Program through an error message "Authentication Fail" when I was trying to login with the sample code (Folder Asterisk 2013)  even though the user name and password is correct.
What else do I need to config?
Here is my code:
`Imports AsterNET
Imports AsterNET.Manager
Imports AsterNET.Manager.Event
Imports AsterNET.FastAGI.Command
Imports AsterNET.FastAGI
Imports AsterNET.IO
Imports System.Text
Imports System.Data.Sql
Public Class Form1
Dim host As String = "<IP_ADDRESS>"
Dim port As Short = 5038
Dim user As String = "222"
Dim pass As String = "222"
Dim conn As New ManagerConnection(host, port, user, pass)
Dim exten As Short = 201
Dim state As String = "state"
Private Sub SimpleButton1_Click(sender As Object, e As EventArgs) Handles SimpleButton1.Click
    Try

        conn.Login()

    Catch ex As Exception
        MsgBox("Error logging on")

    End Try
    If conn.IsConnected Then
        MsgBox("Yo!! Connected!")
    End If

End Sub

End Class
`

Is ami enabled in Asterisk?

You have to  write in manager_custom.conf or  manager_additional.conf files.These are the files present inside asterisk server
// You have to write like this in any one of this file
[abc]
secret = 123
deny = <IP_ADDRESS>/<IP_ADDRESS>
permit = <IP_ADDRESS>/<IP_ADDRESS>
permit = <IP_ADDRESS>/<IP_ADDRESS>
read = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate
write = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate
Then you have to write in your code to connect to asterisk or AMI
Code section
const string DEV_HOST = " <IP_ADDRESS>";
const int ASTERISK_PORT = 5038;
const string ASTERISK_HOST = "<IP_ADDRESS>";
const string ASTERISK_LOGINNAME = "abc";
const string ASTERISK_LOGINPWD = "123";

I am also facing the same problem. In fact i wrote the above piece of code in manager_additional.conf/manager_custom.conf file but still problem is staying in the code.
What should i need to check again in my code or asterisk ?

I am having the same issue:
https://github.com/AsterNET/AsterNET/issues/112

I figured it out: https://github.com/AsterNET/AsterNET/issues/112


[Travis] Put the tmp directory in a ramdisk

Closes #2865 if it works

So this a) breaks specs and b) is no faster

It seems... somewhat faster? 12 hrs 22 sec vs other recent times of around 12 hrs 45 min makes it seem like it's around 5% faster. Failing tests is not great though. :( Probably things inside the tests that either don't know how to handle symlinks or permissions that are different on the ramdisk.
This is probably not worth pursuing if our main bottleneck is CPU time, though. :/


feat: WSGI Middleware

Fix #177

Codecov Report

Merging #180 into master will decrease coverage by 13.25%.
The diff coverage is 72.54%.

@@             Coverage Diff             @@
##           master     #180       +/-   ##
===========================================
- Coverage   80.85%   67.59%   -13.26%
===========================================
  Files          28       28
  Lines        2376     2237      -139
  Branches      401      379       -22
===========================================
- Hits         1921     1512      -409
- Misses        300      606      +306
+ Partials      155      119       -36

Impacted Files
Coverage Δ

sentry_sdk/integrations/pyramid.py
0% <0%> (-78.5%)
:arrow_down:

sentry_sdk/integrations/flask.py
0% <0%> (-75.73%)
:arrow_down:

sentry_sdk/integrations/aws_lambda.py
0% <0%> (-17.95%)
:arrow_down:

sentry_sdk/integrations/django/__init__.py
81.5% <100%> (-3.47%)
:arrow_down:

sentry_sdk/integrations/wsgi.py
88.77% <100%> (ø)

sentry_sdk/integrations/_wsgi_common.py
70% <70%> (ø)

sentry_sdk/integrations/celery.py
0% <0%> (-84.62%)
:arrow_down:

sentry_sdk/integrations/rq.py
0% <0%> (-78.44%)
:arrow_down:

... and 20 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 58ec2e4...0da1530. Read the comment docs.


Exception handling

Catch all exceptions.

Use unity_log to log the exception.

These changes alone will not get exceptions into the player log.   A change to Unity is needed as well https://github.cds.internal.unity3d.com/unity/neutron/pull/62

One of the jobs failed due to my test to check stdout for the exception message failing.
https://unity-ci.cds.internal.unity3d.com/job/25000051/logs/execution
I'm wonder if my approach to testing for the exception message in stdout is reliable.
Is vprintf buffered?  If it is, then calling System.Environment.Exit right after may not reliably get the stack track into stdout (or wherever Unity sends it).

Is vprintf buffered?

I believe it only flushes if there is a newline. Not even sure how well documented/spec'd that is. You could call fflush(stdout);

You could call fflush(stdout);

That's going to be a little more complicated given how unity_log works.  Unity will pass in it's own print func.

I tried adding a \n.  The job still failed.
I hacked in fflush(stdout); and 4 jobs passed.  I think that confirms the theory that buffering is leading to the Environment.Exit call causing the application to exit before the stack trace has been written.
I checked in Unity and the callback we pass in to mono_unity_set_vprintf_func is
void MonoPrintfRedirect(const char* msg, va_list list)
{
    va_list args;
    va_copy(args, list);
    printf_consolev(kLogTypeDebug, msg, args);
    va_end(args);
}

Looking at printf_consolev in LogAssert.h
void printf_consolev(LogType logType, const char* log, va_list list, bool flushOnWrite = true);

With flushOnWrite defaulting to true, Unity shouldn't encounter this instability of the stack trace not being written.
For the tests we depend on vprintf directly.  I'm going to wrap this in a function that will call vprintf and fflush.  This will give our tests the same behavior Unity has and both cases will be safe from this instability.

For the tests we depend on vprintf directly. I'm going to wrap this in a function that will call vprintf and fflush. This will give our tests the same behavior Unity has and both cases will be safe from this instability.

Agreed, I think the instability in testing will not be an issue in unity.


Rename the asf file

Ok, my mistake. Looks like the asf file have to be .asf.yaml and does not work with the "yml" extension. :facepalm:

@vinodkone Could you please help merge this PR? I am still requesting merge permission now.


Update installer to allow installation even while AmiSSL is in use

The current installer's behaviour is to quit with an error if AmiSSL is in use. It would be more flexible if it were to simply install the files, and ask the user if he/she wants to reboot to complete the installation.

I just discovered that something puts a lock on the library(s) while it's in use. Perhaps AmiSSL itself is doing this? I can rename/overwrite other libraries even though they're in use, so the OS itself doesn't lock libraries that are currently open.

I just discovered that something puts a lock on the library(s) while it's in use. Perhaps AmiSSL itself is doing this? I can rename/overwrite other libraries even though they're in use, so the OS itself doesn't lock libraries that are currently open.

Yes, you're right - it is most likely due to: https://github.com/jens-maus/amissl/blob/dd7c2095b8868064bef4cb266f7fc62123d4f73b/src/amissl_libinit.c#L718
which cannot easily be avoided AFAIK, due to the baserel stuff / IElf->CopyDataSegment(), which needs the Elf handle. IBrowse has the same issue.
The AmiSSL installer itself employs some tricks (renaming the libraries) to flush the libraries from memory, otherwise the installer would also fail even if the libraries were resident in memory, but not in use. Of course, this only works if nothing has AmiSSL open. I hope updating AmiSSL via AmiUpdate is not affected by this, as I did advise that AmiUpdate needs to close AmiSSL before trying to update AmiSSL.

Yes, you're right - it is most likely due to: https://github.com/jens-maus/amissl/blob/dd7c2095b8868064bef4cb266f7fc62123d4f73b/src/amissl_libinit.c#L718
which cannot easily be avoided AFAIK, due to the baserel stuff / IElf->CopyDataSegment(), which needs the Elf handle. IBrowse has the same issue.
The AmiSSL installer itself employs some tricks (renaming the libraries) to flush the libraries from memory, otherwise the installer would also fail even if the libraries were resident in memory, but not in use. Of course, this only works if nothing has AmiSSL open. I hope updating AmiSSL via AmiUpdate is not affected by this, as I did advise that AmiUpdate needs to close AmiSSL before trying to update AmiSSL.

It's not just AmiUpdate. ZitaFTPServer has the problem too. I will be updating the installer to shutdown the server first. However, if the user still has their web-browser open then it'll still fail.

It's not just AmiUpdate. ZitaFTPServer has the problem too. I will be updating the installer to shutdown the server first. However, if the user still has their web-browser open then it'll still fail.

Of course, any application that has AmiSSL open will prevent the installer from working. I just mentioned AmiUpdate as a special case.
Anyway, this problem has always bothered me and it is indeed OpenElf() that puts a lock on the libraries. 'CopyDataSegment()unfortunately needs to read relocation information from the file each time it is called (everytime the library is opened). This lock has to be maintained while the library is in memory, otherwise if you update AmiSSL and overwrite the libs, while AmiSSL is in use, if some application then opens AmiSSL it will probably crash due toCopyDataSegment()` reading from the newer file.
I've been looking at the elf.library source code and there just doesn't seem to be a good way around it, in terms of the AmiSSL libinit code. Perhaps the only solution is to make the installer rename the libraries to amissl*.library-old (for example) and at least the libraries can then be installed - the new version just won't be used until after a reboot or if the old version is expunged.

Of course, any application that has AmiSSL open will prevent the installer from working. I just mentioned AmiUpdate as a special case.
Anyway, this problem has always bothered me and it is indeed OpenElf() that puts a lock on the libraries. 'CopyDataSegment()unfortunately needs to read relocation information from the file each time it is called (everytime the library is opened). This lock has to be maintained while the library is in memory, otherwise if you update AmiSSL and overwrite the libs, while AmiSSL is in use, if some application then opens AmiSSL it will probably crash due toCopyDataSegment()` reading from the newer file.
I've been looking at the elf.library source code and there just doesn't seem to be a good way around it, in terms of the AmiSSL libinit code. Perhaps the only solution is to make the installer rename the libraries to amissl*.library-old (for example) and at least the libraries can then be installed - the new version just won't be used until after a reboot or if the old version is expunged.

@ksdhans I figured out a way to preload the required data relocs, allowing the file lock to be released during initialisation (instead of expunge), which means that once users have AmiSSL 5.4 installed, future updates will be able to install even if AmiSSL is currently running or in memory (just as would normally happen on OS3).

Nice! The ZitaFTP Server installer can now shut it down, but it won't help with the AmiSSL update if something else is using it...
Looking forward to AmiSSL 5.4...

Final fix for this is in AmiSSL 5.13

And now that elf.library 54.1 has been released to the public, it is now time to finally close this issue.


Refactor existing code

The Plan for Vic2 World (edit as progress happens):
V2World
Vic2State after V2Country
V2Relations after V2Country
V2Province after V2Country, Vic2State, mapper
V2Pop after V2Province
V2Party after V2Country, V2World
V2Localisation after V2Country, V2World
V2Leader after V2Country
V2Inventions after V2Country, V2World
V2Factory after V2Country
V2Diplomacy
V2Country after V2World, V2Province, GovernmentMapper, mapper
V2Army after V2Country
Vic2Agreement

The plan for mappers (edit as progress happens):
CoastalHoI4Provinces
CountryMapping
GovernmentMapper
Mapper
ProvinceMapper
StateMapper
V2Localisations

Added to milestone so it doesn't get buried again.

Develop a plan for HoI4World and add it here.


Minor text fixes in preparation for v1.0.0 release

I'll use this PR to collect all scattered minor text fixes I find in preparation for the v1.0.0 release.
Others can feel free to push to this as well.

I suggest we also push a "remove whitespace" commit here during the v1.0.0 release call and merge this as the final commit before starting the release procedure.

Sorry - I realised now that maybe you didn't want to merge this before the release...
I saw 3 approvals so I went on.
If this was the intended goal, maybe we could use the 'draft PR' option of GitHub next time?


Reinitialize the cache during the session cache async test

Please note that while we are transitioning from travis-ci to AWS CodeBuld, some tests are run on each platform. Non-AWS contributors will temporarily be unable to see CodeBuild results. We apologize for the inconvenience.
Issue # (if available):
Fixes #1471
Description of changes:
The manual session ID starts with 0x30, which causes the 0x30 cache bucket to unlock on every test. If the random session ID also starts with 0x30, then the bucket is already unlocked and we don't simulate to blocking condition that we want.

Reinitialize the cache for each test in session_cache_async_test. The re-locks the 0x30 bucket.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

:exclamation: No coverage uploaded for pull request head (1471_async_test@936ca9c). Click here to learn what that means.
The diff coverage is n/a.


Migrate examples here

Tasks

[x] Move status-im/js-waku-examples to waku-org orga
[x] Setup Jenkins to publish js-waku-examples to examples.waku.org
[x] Update js-waku-examples to latest code from js-waku repo
[x] Remove Jenkins setup to publish js-waku/examples to https://js-waku.wakuconnect.dev/examples
[x] Update documentation to point to new url
[x] Remove examples folder from js-waku repo
[x] Get content for examples.waku.org (eg. redirect to js.waku.guide/docs/examples)

@jakubgs can you please published the various folders in this repo to https://examples.waku.org?
This is the same than https://github.com/status-im/js-waku/blob/master/ci/Jenkinsfile.gh-pages
As per steps above, I will then delete https://github.com/status-im/js-waku/blob/master/ci/Jenkinsfile.gh-pages and https://github.com/status-im/js-waku/tree/master/examples
Thanks!

Okay, but is there's no main page for this as far as I can see.

Okay, but is there's no main page for this as far as I can see.

Noted. Please proceed, will add to future tasks.

But... what should be on the main page for now? Just 404 error?

But... what should be on the main page for now? Just 404 error?

Just 404 please.

The eth-pm example appears to be broken:
+ yarn run build
yarn run v1.22.19
$ react-scripts build
Creating an optimized production build...
Failed to compile.

TS2345: Argument of type 'ArrayBuffer' is not assignable to parameter of type 'Uint8Array'.
  Type 'ArrayBuffer' is missing the following properties from type 'Uint8Array': BYTES_PER_ELEMENT, buffer, byteOffset, copyWithin, and 24 more.
    14 |     salt: utils.bytesToHex(salt),
    15 |     iv: utils.bytesToHex(iv),
  > 16 |     cipher: utils.bytesToHex(cipher),
       |                              ^^^^^^
    17 |   };
    18 |
    19 |   localStorage.setItem("cipherEncryptionKeyPair", JSON.stringify(data));

I'll comment it out for now.

The site builds have been failing because of this since 8th of August:

Created the CNAME: https://github.com/status-im/infra-misc/commit/4f80ea3d

Well, the first version works: https://examples.waku.org/web-chat/

@jakubgs looks like the Jenkins build hasn't run since 7 September: https://ci.infra.status.im/job/website/job/examples.waku.org/
Am I missing something?

Btw, because there's no yarn.lock files the yarn install step is about 5x slower:

Btw, because there's no yarn.lock files the yarn install step is about 5x slower:

Yes I know, I personally don't really mind. Is it an issue on your side?

Not really, just pointing it out. Tell me if this happens again. I'm not 100% sure it was fixed.

One task remaining

@hackyguru are you happy to take this over? the root page: https://examples.waku.org returns a 404, we need to decide what it should return/direct too and do it or get help from Comms Hub.

@fryorcraken Assigned the issue to myself. I'll get this done and request for a review

For the time being, examples subdomain is being redirected to examples section of waku guide. We can revamp this once we have our refactored docs in coming weeks


Develop upstream sync 240401

retest Ubuntu-GPU-single please
retest Ubuntu-CPU please

retest Ubuntu-GPU-single please

retest Ubuntu-GPU-single please

Temporarily removed local deps in lit tests (ref)
This should be reverted once the upstream includes these changes from llvm: lit_test : check if there is already a deps key in kwargs

retest Ubuntu-GPU-single please

retest Ubuntu-GPU-single please
retest Ubuntu-GPU-multi please

retest Ubuntu-GPU-single please

retest Ubuntu-GPU-single please


WIP // Using nginx as a caching proxy

to relieve S3 (in our case) a bit from stress, we cache queries via nginx
This is still WIP, I'll check in next week after we have this running for some time.

not a good idea :sob: as this would remove any authentication the BR requires.
Only a good idea if no authentication is needed. :sob:

I think we are good to go, will test this our properly and update the PR.
@oliviermichaelis, this relates to https://github.com/boring-registry/boring-registry/issues/194 and may solve this already.

Was this feature successfully tested in production?

This feature is running in production since a week. I would leave it running with the changed /metrics behaviour during the weekend and give a go/no-go after this.
Thanks for the review

The cache was running since 4 days now with the changed /metrics behaviour as well - looks good to me ;-) @oliviermichaelis


Add minimal README

No API docs yet

I think this is enough to publish to npm.  Thoughts?

I think that should be enough to get up on npm for now.


Carbon Addons

This is a RFC proposing a new set of tooling and conventions for Carbon Addons.
This work stems from the Addon repository we have been building on IBM Cloud and is based on research that was conducted with various development teams working on the IBM Cloud platform and services that run on that platform.
This is definitely an extremely long RFC, there's a lot of partially completed thoughts in it. If you would like more details on anything let me know. Many of concepts have already been developed within our business unit.
VIEW RFC HERE <----------------

Thanks for the feedback @asudoh! I definitely agree that the focus should be on tooling and I think there is a lot of opportunity to make sure the tools also work as standalone packages to allow for Addon teams to choose what they need.
I also love the idea of establishing a bit of a hierarchy around what's required and what's not. Maybe there's an opportunity to gather various stakeholders across different business units have a quick session to work out what we think we should be strict on what are more of guidelines.

@loganmccaul @asudoh great stuff! Couple RFC-wide comments. Primary point being separating framework-specific items from framework-agnostic items.
tooling requirements vs specific tooling choices
Focussing on specific tooling might make it difficult for non-React implementations. When determining add-on library structure, it would help to document expected  functionality rather than specific tools to accomplish that functionality.
For instance, Dev Server (Tooling) - using Parcel to create a server might not be the best choice for the carbon-vue or carbon-angular and wouldn't work when creating Vanilla components. And on our team we've run into some issues with Parcel (such as bugs when creating maps). So for planning purposes, would it be possible to just focus on what an add-on library should be able to do, and then tooling could be determined from the functionality requirements? So, instead of
The Development server is a basic Parcel server that is used to develop the
Carbon Addon components. This can be customized to use a custom server
through the CLI so you can properly make API calls without CORs issues.

it could be:
The Development server is used to develop the Carbon Addon components.
This server should be customizable to use a custom server through the CLI
so you can properly make API calls without CORs issues.

The requirements could be a living document, getting updated as new needs arise. Once you have requirements, there would be subsequent RFCs to determine tooling that would be best suited to accomplish the functionality according to the technological ability of each framework.
The second benefit of requirements vs specific-tooling-choices is around future-proofing the system. If there are functionality requirements in place, the tooling could be revisited in the future as technology matures (or is abandoned), making new choices according to the requirements instead of the old tool's functionality.
This would also allow a new framework (cough web components cough) to determine tools from required functionality, rather than trying to use an existing tool which may not be the best choice for the new framework.
framework agnostic vs framework specific
Another item is around folder structures, specific files and file-types and what would live in an add-on vs what's in the canonical.
For instance, the File Structure section - there are some files which would be framework-agnostic, like any of the .mdx files, but then that structure includes React-specific files like (NAME).js, which is not something that would exist in a carbon-angular component (which uses .ts files), a carbon-vue component (.vue files), or a vanilla component (.hbs files).
So instead, it could be documented like so:
Agnostic file structure

File
Description
Prefilled Code (%)
Required

_styles.scss
Styles for this View component. Prefixed with a chosen prefix for this Addon. Styles are in scss to match how Carbon handles styling.
01
Yes

code.mdx
The documentation mark down file for this component.
20
Yes

usage.mdx
The design documentation for how this component should be used.
00
Yes

style.mdx
Design documentation on the style of this component.
00
Yes

Storybook file structure

File
Description
Prefilled Code (%)
Required

skeleton.js
The loading skeleton for this component.
20
Yes

React add-on file structure
agnostic and storybook files plus:

File
Description
Prefilled Code (%)
Required

index.js
Exports the View Component.
100
Yes

(NAME).js
The primary React component.
20
Yes

(NAME)-test.js
The tests for the primary React component.
20
Yes

Vanilla add-on file structure
(if vanilla didn't use storybook, it would just inherit the agnostic files)
agnostic files plus:

File
Description
Prefilled Code (%)
Required

(NAME).config.js
Exports the component configuration.
100
Yes

(NAME).hbs
The primary Vanilla template.
20
Yes

tests/(NAME).spec.js
The tests for the primary Vanilla template.
20
Yes

A change like this would work for any content, not just files. The main question being: "Is this a React-specific item, or would this item work with all the frameworks".
This would also give us something to test. For all add-ons, Carbon would test for the existence of the .scss file and the three .mdx files, but then there would be react-add-on-library-specific tests for (NAME).js's existence. These automated tests could ensure no add-on gets merged without the minimum-required files.

@scottnath Thanks for bringing this up! I've been struggling on how to communicate this idea outside of the React world and the work we've already done within IBM Cloud. I definitely don't want Carbon Addons to be specific to one language, and the concepts themselves should be agnostic.
One idea I've been thinking of is breaking down templates by language. So instead of using a View template I would specifically use a React:View template. Those files can be made up of the language agnostic structure and the language specific files.
I'll spend some time tonight updating the RFC to remove the specific development solutions as well as the generalizing the work to be more broad than just React.

@scottnath I've updated the RFC with more agnostic language. The primary changes are

When initializing a Carbon Addons library a language needs to be selected.
Templates are specific to a language and the required files and implementation details can differ per language. However, the general concept of a template can probably be shared across languages.
Added possible file types for each template and removed any specific reference of React to reflect above.

Let me know if that helps, or if you feel that the RFC is still too specific about implementation details.

Just to narrow in on things, could you expand on the goals section, namely:

To decrease front end development time.

What specifically are we addressing and how do they contribute to decreasing development time?

To encourage consistency across a single business unit.
To create a centralized place for reusable front end development patterns within a business unit.

Is the second goal a way to achieve the first goal in this list? Or is it truly a goal in and of itself? If it's a standalone goal, what's the value of a centralized place for reusable FED patterns?

To allow for more reusability across IBM and across business units.

How would this goal relate to the goal of creating consistency across a single business unit? Often times, they can feel like they contradict each other so was curious how you are thinking this could play out.

With respect to discrete aspects of this proposal, I think tooling could easily fall under the new @carbon/cli package.
I think our goal is to try and do both single-purpose CLI tooling, for example @carbon/contribute for contributing and @carbon/upgrade for upgrading, alongside a consolidated tool @carbon/cli. Under the hood, what this means is that single-purpose CLI tools will export their commands such that @carbon/cli can also register them.
I strongly agree with the fundamental project structure, namely how we build out components and docs for these components, and I feel like this can take on a shape that mirrors Carbon's structure. This would mean that any tooling we build into @carbon/cli (for example the sync command) could also be helpful in these projects, alongside any kind of scaffolding or running that we may bring into that package.

Ultimately, what I think we'll see happening is the formation of "design sub-systems". These inherit what they want from the broader "design system", but ultimately control how their brand delivers the design system in product.
On the design system side, this means that we open up our system into several categories:

Elements: design elements from the design language represented in code
Core components: components built and maintained by the core team
Community components: components built and maintained by community contributors, these components have broad use but may have broad scope or require domain expertise that the core team lacks

Within each of these categories, we offer a combination of distinct, single-use packages alongside preconfigured bundles of functionality. For example, with elements we offer standalone packages for colors or type but ultimately bundle them together in a single package, @carbon/elements.
The job of the sub-system team is to then grab either preconfigured bundles, or craft their own bundles for how they want to deliver components in code for their particular brand. Hierarchy-wise, this may look like:
- design system
  - accordion
  - accordion-react
  - button
  - button-react
  - vanilla
    - accordion
    - button
  - react
    - accordion-react
    - button-react

The sub-system then has a couple of options:
# Use design-system/react directly
- sub-system
  - react
    - design-system/react

# Use components as-needed
- sub-system
  - react
    - design-system/button

The sub-system also is a place to start adding in layers brought up in this RFC, namely data/domain requirements for components. It also is the location to consolidate front-end code, namely around things like configuration for tooling, styles, and components themselves.
It also includes the documentation site reference in this RFC, and can pull in content from the upstream system (like component examples, guidance, etc.) so that referencing something in the sub-system is a one-stop shop, and will let us nest sub-systems as needed (a common problem now with add-ons is their hierarchy).
Obviously a lot of this stuff isn't worked out yet, but it does feel like we're starting to scratch at a similar itch when it comes to figuring out how to address the current add-on situation. Just wanted to leave some thoughts on this RFC for context, and to think about how we can further align things 😄

Hey @joshblack! Thanks for the feedback, it's great to hear what the core Carbon team is thinking about!
I'd love to expand on the goals.
To decrease front end development time.
This is the time it takes to develop the product, not the component library. For components, the development time saved comes from reusing styles, actions, and patterns. Same as the value Carbon provides today.
Data Hooks and Connected components come from research within the Cloud business unit. We found that developers spent a significant amount of time learning and setting up APIs.  Data Hooks and Connected components exist to decrease the time it takes for a developer to use an API.
To encourage consistency across a single business unit.
This goal does not directly impact development time. Instead, this goal derives from Cloud design's research. The research uncovered tons of different implementation patterns. This can lead to a whole multitude of UX issues.
To create a centralized place for reusable front end development patterns within a business unit.
A centralized place also allows for communication and awareness of patterns already created. Within Cloud, teams have created their own component libraries to share between microservices. Other teams can't discover and use the existing components because these are team specific .
You are right. This one is more of a solution to the above goal. I'll play around with the wording and update the RFC.
I'd love for you to expand a bit more on why a centralized location can lead to inconsistency across a single business unit. From our perspective we have a few different component libraries that could be considered addons. Each is maintained, built, and communicated differently across IBM Cloud. To us, a centralized location would allow for more collaboration between the team's developing on IBM Cloud. We might be going down the wrong path though.
I'll update the RFC with the above explanations.

I love this! The more we could combine the Carbon Addons concepts and the Carbon tooling the more scalable each can be. I agree that the structure of an Addon and the structure of Core Carbon should align. Carbon can become more of a foundation and ecosystem for design systems than a single design system itself.

These plans for a design sub system are great! It allows each business unit to control components and how they get used. Additionally, I love the plans you all have so far.
There is room to expand on both concepts. The data and domain specific stuff can all share a common tool set with the rest of Carbon's CLI. I can see a future where patterns such as "Login with IBMid" or other general IBM actions live within a core design system. Regardless, having one CLI would make it easier for business units to know what's available. It also allows for everything with the Carbon name to be built and developed the same way.
Maybe this RFC should take in the concepts you brought up above and be renamed Carbon Ecosystem 😄

I reference ongoing work within the Cloud business unit as well as internal developer research through the RFC and my responses. If anyone is interested in learning more about those feel free to DM me and I'd be happy to share resources.

@loganmccaul I've been thinking about this problem a lot. Essentially, applying Gatsby's theming model to design systems. I think by providing an infrastructure to develop, document and deploy bespoke components with Carbon at the engine, we could develop a really powerful tiered architecture.
We’ve seen a similar problem play out in the IBM websites attempting to use the Carbon website as a model. Teams that originally cloned the repo, or devised their own solutions are coming back to use the Gatsby theme because the infrastructure makes it a happy path to best-practices and shared contribution.
I wanted to stress the biggest advantages, in my opinion, from Carbon owning and supporting the tooling around addon development

Owning the tooling and distribution pipeline means we gain insights into how teams are using Carbon and what they're making with carbon components
We can make guarantees about the components, their dependencies, and the carbon version that would be much more difficult if we didn’t own the tooling
We can use this use this information to make informed decisions about future core components
Free, supported infrastructure means increased Carbon adoption, and easier migration to major versions

My biggest concern with the RFC as-is pertains to the Connected/Hosted components as well as the Data Helpers.
This tooling seems out of context and prescriptive for a design system/front-end development kit to take an stance on. Teams might have their own opinions on things as simple as even using presentational/container-components. For example, Dan Abramov recently walked back his opinion on this pattern. The RFC pushes even further past that point of possible contention and gets into Hosted vs. Connected components? This sort of stance on data fetching at the business-unit level is untenable in my opinion.
In addition, by including things like data-fetching helpers we're pushing the scope of what logic gets put into an addon component while also restricting the teams that could take advantage of shared components. This makes it harder for us to support the addon infrastructure tooling and decreases the likelihood that a component could bubble up to core.

I also wanted to share a couple ideas here that could be fundamental to flexible addon architecture and greatly increase their utility in a way I'm not sure exists for other component libraries yet.
Addon composability
Flat vs tiered design system architectures
As is, addons would have a flat model whereby any team or individual could create an addon and it would be in a pool of peers. This could result in perhaps importing from several addons in addition to Carbon Core.
Design System Tiers - EightShapes - Medium

An interesting model might be making these systems composable (similar to Gatsby themes). In the end, addons and their documentation could all compose with each other as well as Carbon Core before shipping as a bespoke bundle or theme. I think this would result in the ideal dependency experience for developers importing and using an addon.
This would also allow us to develop tiers of addons with progressively stringent requirements (enabled per-addon through configuration). This pattern would both empower experimentation and flexibility without risking the integrity of higher-quality, upper-tier addons potentially shared between business units.
We could have increasing requirements from code formatting to themability:

Finally, I think a truly composable addon architecture could expand beyond the current component/react focused solution to include things like themes as well as pure documentation via guidelines.

Hey @vpicone! Sorry for the late response, I must've missed your comment. Thanks for taking the time to read and provide feedback!
I  agree about the Gatsby model. I actually haven't thought about this from the concept of Gatsby Themes. There is definitely a lot we can learn and understand from the way they've set things up.
I also completely agree with your assessment of advantages with one exception. Ownership and development of these tools needs to be shared across business units as well as Carbon. Carbon is definitely in the unique position to be at the center of the solution, but with the numerous different business units in IBM it may be an impossible task for one team to maintain a system and meet each org's needs.

You bring up an excellent point about being too prescriptive with anything that is data connected. With templates I hope we're not enforcing any practices.  I can help share some of the background and template concepts that might be missing from the RFC.
First, when we began this work within IBM Cloud we started by interviewing different front end developers in our business unit. The number one pain point we found was around working with APIs. For the most part developers had every component they needed from Carbon, but they didn't have a way to understand or use the APIs that make up IBM Cloud. Without a place to share or reuse API calls, each team was spending a large amount of time reinventing the wheel. For us, one of our goals was to minimize reinvention. I don't want to go into too much detail on the research here, but if you're interested I'd be happy to share a lot of our research findings internally.
Second, we should never enforce specific development patterns. That's one of the reasons why templates need to be extensible. The Data Hooks and Connected components in the RFC are examples of components that work well for IBM Cloud. There's no reason a template can't exist for other data driven aspects. Apollo queries or basic fetch requests could be templates for example. Hopefully, if an existing template doesn't meet a developers need then they will create a new one. It's one of the reasons that a Connected component is made up of Data Hooks and Views. It allows the developer to decide which component they want to use. Connected gives them the full picture, Data Hook gives them the data, and View gives them the look and feel with each functioning on it's own. (Except Connected I guess :smile: )
I do agree that data fetching, smart components, or anything specific to an API doesn't make sense in core Carbon, but they can provide significant value for product developers. This is one of the reasons that I'm hoping the creation of these tools becomes shared across business units. Each business unit has their own needs. If we share the solutions to those needs we may find a lot of opportunity to reuse code across IBM.

This is really cool! I'm unfortunately not too familiar with how Gatsby theme's work under the hood, but if we we're able to streamline and share work through composing existing patterns we can truly create an extensive system.
I also really like the idea of this being more than a component library and instead a pattern of best practices, tools, and assets that allow each group down to the individual development team to share and form their own environments.
I'd love to learn more about how this could work from a technical perspective if you have time. There's also an opportunity for a bit of a workshop here to share and combine the different concepts that are being discussed.

@loganmccaul, I didn't realize quite how far you guys were along in the path towards making this a reality for your team. This this next coming milestone I think we plan on dedicating the time and resources to get this right across business units.
In regards to tool ownership, I definitely don't mean owning the individual addons or even necessarily the space where addons live, I mean the tools and infrastructure for building addons with carbon that have portability between business units as a primary directive. The first image my comment is what we don't want, the tooling I'm talking about owning is much closer to the arrows and foundations of the addons than the addons themselves. That tooling, I think, could be sufficiently abstracted across teams and business units and provided open source via Carbon.
Re: data stuff
I think one thing we might differ on is the end goal of addons.

Empower BU and teams to distribute and reuse accessible components built with Carbon
Allow for the distribution of those same components across business units at IBM, fostering an ecosystem of shared interest

The ultimate challenge here is going to be crushing #1 while at the same time not sacrificing the ability of us and future developers to crush #2.
By including hooks, caching, and opinionated data logic in a third party component library, we stand the risk of exposing/depending on business logic that makes these addons not only closed source, but also prevents us from accomplishing #2.
As someone who came from writing product code to the framework side, I can definitely empathize with the front-end developers API plight. While I think cloud should certainly be empowered to write and share their own data driven components, I have a really uneasy feeling of incorporating data fetching architecture into components meant as an addon to a third party component library.
Could you imagine if libraries like material-ui, semantic-ui, or polaris had opinionated data fetching elements to their component libraries? Although you're separating concerns between view and data components, intermingling those concerns in the library as a whole will invariably grow to serve the business units needs and make those components less and less portable across BU lines.
I'd implore you to reconsider including the data hooks in this RFC and distributing them separately for both the increased portability of the addon components and the flexibility in maintaining your data fetching hooks.
An example: what if you had to make a breaking change to one of your data fetching hooks do to an API change? Now you have to make a breaking change to the component library as well and version appropriately. To me it just doesn't make sense having these things in the same package just for the convenience of a single import. There's also nothing stopping you from packaging carbon-addons-cloud and react-hooks-cloud into a single cloud-ui package. I think we really, really just don't want them to intermingle, it drastically over complicates the scope of addons and the tooling around it.
I hope that wasn't too dramatic haha, really looking forward to figuring this out together.


Added About and Open Source Section

Description
Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context.
List any dependencies that are required for this change.
Fixes #281
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] Any dependent changes have been merged and published in downstream modules

Reviewer: Vinit Shahdeo

I have added the required section .
https://drive.google.com/file/d/1OjVRLTuvBH-tqvYccbzK1SV8F2oq7_Kc/view?usp=sharing
https://drive.google.com/file/d/1JRuSO9UYRrPcd2xu8EBAiM8IiQp59vgz/view?usp=sharing

Please review and merge @amaaniqbal @vinitshahdeo

Changes look good to me. Can you try resolving merge conflicts by pulling the latest changes from the upstream before pushing?


Fix "Self-referencing association" error for traits

This originally came up in https://github.com/thoughtbot/factory_bot/pull/1017, which includes a failing spec.
Self-referencing association
The "Self-referencing association" error was introduced in e4a3d25711ffcc7945a49bdf67bdf564d1cb27e4 to catch this:
factory :user do
  user
end

This is still working as expected
Trait referencing association with the same name
When the error was moved from Factory into AttributeList in e3bf491dd6af2b6c5c110c4a795db65bb458e3da it started catching associations with the same name as a trait as well:
factory :post

factory :user do
  trait :post do
    association :post
  end
end

The AttributeList doesn't know when it is part of a trait definition rather than a factory definition.
It just raises an error if its name matches the name of the association:
https://github.com/thoughtbot/factory_bot/blob/cffa56e4c8c55bb1467e14e6fb885a6b6fafc54f/lib/factory_bot/attribute_list.rb#L56
While I think naming the factory and trait the same thing is confusing, I am not convinced it should raise an error.
Self-referencing trait
What should definitely raise an error is a self-referential trait, but this will currently give us a trait that calls itself recursively:
factory :user do
  trait :bad_trait do
    bad_trait
  end
end

I think it would make sense to catch this and
raise TraitDefinitionError, "Self-referencing trait..."

Just merged https://github.com/thoughtbot/factory_bot/pull/1294 which addresses this issue.


v2 Beta - duplicate cards shown in preview while editing

Similar to v1 issue - a duplicate card shown in the preview when editing. In this case, it's a sonos card.
2.0.0 beta

I really thought this was fixed! I will take a closer look at that!

Thanks - I've only seen it once so far when adding the Sonos card. Sonos card is a tricky one as it often cancels the popup when pressing some of its buttons. I guess it mush be doing something that interferes with your code.

You were right about the cache/reload. After a restart of HA, I added another vertical stack and added a sonos card - showed correctly this time.
Hopefully that has cheered you up as I know you said you'd put a lot of time into fixing that!
I'll report back if I see anything else weird.
Good job!

Yeah! I was a bit disappointed when I saw your issue 😂

Sorry - I know that sinking feeling!
All good though :)


Setting memory size of vagrant node is not working

From @aleksijohansson on October 27, 2016 20:48
If I choose the memory size of 2048MB kontena still creates the nodes with 1024MB of memory. This happens if I create one node at a time or multiple nodes at once. Kontena CLI version 0.1.6
Copied from original issue: kontena/kontena#1244

Vagrant related issues should be reported in the https://github.com/kontena/kontena-plugin-vagrant repository.
This is a regression bug with 0.16, I will whip up a PR in few minutes.


Add LICENSE file and update README

The LICENSE file is required for Linux packaging. The README has been updated to match the LICENSE file. This fixes #12.

Thank you, @massand!
Is merging this pull request enough to satisfy any Linux packaging requirements, or do I need to release a new version (that includes this LICENSE file) on crates.io?

Thank you, @massand!
Is merging this pull request enough to satisfy any Linux packaging requirements, or do I need to release a new version (that includes this LICENSE file) on crates.io?

To pick up the license file, a new version would need to be published on crate.io. The latest version of the cargo tool (cargo publish or cargo package commands) should automatically pull in the LICENSE file path into crate metadata. You may also need to publish a new version of inotify and notify crates for this to be picked up, depending on version used to publish this chain of crates.

To pick up the license file, a new version would need to be published on crate.io. The latest version of the cargo tool (cargo publish or cargo package commands) should automatically pull in the LICENSE file path into crate metadata. You may also need to publish a new version of inotify and notify crates for this to be picked up, depending on version used to publish this chain of crates.

Thank you, I'll publish a new version as soon as I find some time.
There have been no breaking changes since the last release, so this can just be published as 0.1.5, which means it'll be picked up by dependencies automatically. A new inotify release should not be necessary, and I  have no power over notify anyway.

Thank you, I'll publish a new version as soon as I find some time.
There have been no breaking changes since the last release, so this can just be published as 0.1.5, which means it'll be picked up by dependencies automatically. A new inotify release should not be necessary, and I  have no power over notify anyway.

Version 0.1.5 has been published.

Version 0.1.5 has been published.

@hannobraun Any plans to bump the release for inotify-rs to pick up the inotify-sys 0.1.5 crate? inotify 0.9.2 depends on inotify-sys 0.1.3.

@hannobraun Any plans to bump the release for inotify-rs to pick up the inotify-sys 0.1.5 crate? inotify 0.9.2 depends on inotify-sys 0.1.3.

As I said earlier, the new version will be picked up by dependencies automatically. inotify-sys = "0.1.3" is the same as inotify-sys = "^0.1.3", which means >=0.1.3, <0.2.0 (documentation).
Unless other crates in the build prevent it by using more specific version requirements, the newest version will always be chosen when running cargo update, or when running a build without an existing Cargo.lock.

As I said earlier, the new version will be picked up by dependencies automatically. inotify-sys = "0.1.3" is the same as inotify-sys = "^0.1.3", which means >=0.1.3, <0.2.0 (documentation).
Unless other crates in the build prevent it by using more specific version requirements, the newest version will always be chosen when running cargo update, or when running a build without an existing Cargo.lock.


latency is a function of buffer depth, not a constant

For example, cable modems have about 7-10ms RTT latency to the head end. DSL is often worse 16ms-30ms depending on interleave.
It is the buffer depth that is what causes the latency under load. And that is something netem doesn't really do "right" - what I typically do is setup a byte fifo on one interface to emulate that, and netem - with a proper emulation for loss and full path delay on the other, with a more correct limit.
If you are going to have a snarky test tool, it would pay to get this part right. Otherwise you aren't going to see #bufferbloat in all it's glory.

I agree, it would be nice to be able to model network conditions more realistically, but I think I would be difficult to build a portable abstraction. You're better off just using the low-level tools at that point. That said, I accept pull requests.
This was never meant to be a "snarky" test tool. In fact, the name was a complete afterthought, for better or worse. I wrote it so I could easily test systems I work on under more extreme conditions.

The behavior of a fixed 250ms delay is very, very different from a system with 250ms worth of buffer. 250ms worth of buffer ramps up, WAY faster than 250ms delay does.
http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html
I will think about constructing a patch. Have you seen https://github.com/ravinet/mahimahi ? These guys made the opposite mistake in their code, having an infinite buffer.

Again, I don't disagree with you at all, and I actually appreciate your concern considering many others have been seeing this as a joke. Unfortunately, I just haven't had the bandwidth or the wherewithal to build it into a more compelling tool. That said, the motivation was really more to raise awareness of failure injection as described in my blog post.
I haven't seen mahimahi. Do you have more context for that? The readme is pretty lacking.

I honestly feel that these sorts of changes need to be submitted to the projects responsible for actually affecting the network traffic. (netfilter, ipfw, etc) All this project really does is provide an abstraction to the configuration of said tools using existing technologies. I think that this sort of thing is outside the scope of Comcast.
That being said, if you're aware of a method to more reliably call upon the use of this buffer you mentioned by way of a rule for either netfilter or ipfw, @dtaht, let me know I can I add a configuration rule generation for it.

I have asked my lists to see what they can do to help.
The actual behavior of cable modems is pretty well explored here, in the real world: http://burntchrome.blogspot.co.nz/2014_05_01_archive.html
The above link shows how someone equipped with their own home router and a modern openwrt  firmware can vastly improve their cable modem experience.
The cable modem behaviors that are so bad are well known, and the DOCSIS 3.1 standard addresses much of the problem, on the uplink side, but not the downlink side. That, unfortunately, is taking a while to roll out.
http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf
And the clearest description of how that works is here: https://tools.ietf.org/html/draft-white-aqm-docsis-pie-02
As for mahimahi, it uses linux containers to create delay, loss, and so on, in a very nice, flexible manner (but as I said, they too got their FIFO design wrong, being infinite. They have a codel patch in a branch that I keep meaning to get around to fixing up, but it would be nice if they had a fixed length byte fifo built into their code also)

and I feel your pain, regarding the snark. Far too many people have the ability to criticise, and far too few, seemingly, the ability or time to do something constructive. Keep at it! The publicity will die down, and hopefully your tool and concerns as you expressed on your blog http://www.bravenewgeek.com/sometimes-kill-9-isnt-enough/  will be understood and addressed by more people that can do constructive things. Eventually.


refactor: migrate to postgresql

closes #16

nice, although was thinking we just remove this dependency from the services and use the change feeds supplied by the ORM directly
Similar to what I've done here: https://github.com/PlaceOS/triggers/tree/refactor/pg-migration
This all mostly works (haven't had time to migrate specs yet) and Pulse needs an update to support Int64's
Pulse error here:
https://github.com/PlaceOS/triggers/blob/refactor/pg-migration/src/app.cr#L107-L109


Commenting a selection with ctrl + K, C is not selection-aware

Issue Type: Bug
If I have a line that looks like this:
if (this.configProvider.config.permissions.adpRequestAVLast &&
and I select 'this.configProvider.config.permissions.adpRequestAVLast', then hit ctrl + K, C, I would expect the result to look what it does in visual studio, which is this:
if (/*this.configProvider.config.permissions.adpRequestAVLast*/ &&
Instead, it comments the entire line like this:
// if (this.configProvider.config.permissions.adpRequestAVLast &&
If I place my cursor on the line without selecting anything, then this behavior is expected, if I select only a part of the line, it makes more sense, and is more consistent with visual studio to use an inline comment.
VS Code version: Code 1.40.2 (f359dd69833dd8800b54d458f6d37ab7c78df520, 2019-11-25T14:54:45.096Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (4 x 2808)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.83GB (9.23GB free)

Process Argv

Screen Reader
no

VM
0%

Ctrl+KCtrl+C is the default shortcut for editor.action.addCommentLine (Add Line Comment), so what you're reporting isn't a bug.
Maybe you want to use editor.action.blockComment (Toggle Block Comment) when some text is selected, and editor.action.addCommentLine -- or alternatively editor.action.commentLine (Toggle Line Comment) -- when none is selected. You can do this by assigning the same keybinding to both commands but making one test editorHasSelection in its when-expression and the other test !editorHasSelection.

This has a side-effect of making a block comment when I select multiple lines at the same time. In this case, line comments are better, as you can do a block selection to partially clear them instead of uncommenting the entire thing, and re-commenting the desired lines one by one or with multiple actions.

https://stackoverflow.com/questions/58803218/vscode-key-binding-with-when-clause-for-partial-line-selections @ralaul is this you?

It isn't

Pinging @alexandrudima who seems to be a team member specializing in keybinding issues. Maybe he has an opinion on the SO post's suggestion about adding a when clause context to make this possible.


New Color customization option editor.activeBackground

Would it be possible to add a workbench.colorCustomizations  that only effects the background color for the active editor. So in addition to having editor.background which is the default editor background we can highlight the active editor with a different color so its easier to see which editor has focus. The tab active color customizations aren't a good solution.

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

Here is an example use case: I would like to see more easily if a file is part of my workspace or not.
See related question at Stackoverflow: https://stackoverflow.com/questions/75181580/higlight-files-which-are-not-from-my-repository


foldl and foldr gives different results on gpu vs cpu in tensorflow 1.4

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): - Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): - Ubuntu 16.04
TensorFlow installed from (source or binary): - source
TensorFlow version (use command below): v1.4.0-3-g5addbae, 1.4.0
Python version:  2.7.12
Bazel version (if compiling from source):  0.7.0
GCC/Compiler version (if compiling from source): 5.4.0
CUDA/cuDNN version: default
GPU model and memory: 1080ti (11GB)
Exact command to reproduce:
See code below

Describe the problem
While testing foldl and foldr, I get the expected result when run on cpu, but get a zero result when running on gpu.
Source code / logs
import tensorflow as tf
with tf.device('/gpu:0'):
els = tf.constant([1.0,2.0,3.0])
f = tf.foldl(lambda a, x: a + x, els)
with tf.Session() as sess:
print tf.GIT_VERSION,tf.VERSION
print sess.run([els,f])

Result:
v1.4.0-3-g5addbae 1.4.0
[array([ 1.,  2.,  3.], dtype=float32), 0.0]
The last number should be 6.0, ie the sum of the input array.  I get this if I change the device to /cpu:0

I also reproduced the big with the pre-built binary version installed via pip:  v1.4.0-rc1-11-g130a514,  1.4.0

This works on a mac with gpu and tensorflow 1.1.  So this seems to be a regression in 1.4

Further testing...  Using the 1.4 pip install works.  So either the bug was fixed in the 1.4 branch or there is a problem building.  No errors during build, however.

Testing further, this seems to be related to this error message:
tensorflow/stream_executor/cuda/cuda_driver.cc:936] failed to allocate 72.44M (75956224 bytes) from device: CUDA_ERROR_OUT_OF_MEMORY
It looks like a memory error happens, but this does not cause the task to fail.  It just causes in incorrect result.
I would suggest that it is better that the job fail than have a wrong answer

@dloyer do you have the stack trace? It should definitely propagate up.

It has been 14 days with no activity and this issue has an assignee.Please update the label and/or status accordingly.

There is no error thrown to the client, just a incorrect answer, so no stack trace.


Run ECCV2022-RIFE on AMD ROCM

I created a venv in the ECCV2022-LIFE folder, started the
pip3 install -r installation requirements.txt
and then I installed my torch, torchaudio and torchvision in this venv in order for rocm to start working on my RX 6600 video card
pip install torch==2.0.1+rocm5.4.2 torchvision==0.15.2+rocm5.4.2 torchaudio==2.0.2+rocm5.4.2 -f https://download.pytorch.org/whl/rocm5.4.2/torch_stable.html After that, I downloaded a demo video from readme.md and rife_trained_v6 tried to do frame interpolation,
(venv) [jorj@jorj-systemproductname ECCV2022-RIFE]$ python3 inference_video.py --exp=1 --video=demo.mp4
Loaded ArXiv-RIFE model
demo.mp4, 1342.0 frames in total, 25.0FPS to 50.0FPS
The audio will be merged after interpolation process
  0%|                                                                                | 0/1342.0 [00:00<?, ?it/s]Segmentation error (the memory stack is flushed to disk)

As you can see above, I get an error when trying to use it, can you help me fix the error? I had no problems using rocm with stable diffusion a1111, ComfyUI and ChaiNNer.

Bruh, i forgot to use HSA_OVERRIDE_GFX_VERSION=10.3.0 LD_PRELOAD=libtcmalloc.so.4


require node 10

Description

Update readme to clarify that node 10 is required
Remove travis run for node 8

Related Issue
#39
Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have signed the Adobe Open Source CLA.
[X] My code follows the code style of this project.
[X] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[X] All new and existing tests passed.

Codecov Report

Merging #38 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #38   +/-   ##
=======================================
  Coverage   94.98%   94.98%
=======================================
  Files          16       16
  Lines         479      479
  Branches       66       66
=======================================
  Hits          455      455
  Misses         24       24

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 2fa8248...f221344. Read the comment docs.


Don't show toastr when Session expires

Hi @shakee93,
I want to clear all previous toaster messages if session expires, for example, let's say the session expires and if user clicks on any link then User is redirected to Login page with toastr being shown with errors message, but I don't want to show that error toastr instead I am showing some other message, could you help me achieve this?
Thank you,

@kashifullahwebdeveloper sorry for the delayed response. have you been able to resolve this issue ?

@shakee93,
Thank you for reply, yes, I have.

Great !! i am closing this issue. let me know if you need any assistance.
Thanks.


Need to add some github-actions

Some basic Github Actions needs to be added

Stale Bot
Husky to run ESLint at pre-commits and pre-pull-requests
DeepSource (https://deepsource.io/)
Welcome and Greetings Bot

I would like to work on this issue as well as love to learn something new
please assign me @yashsehgal

Thanks for showing your interest. Definitely, You can get started with this one.

@SamikshaSankar any updates?

Yup... Actually my exams going on...before 22jun I will be complete this task

please assign it to me under LGM-SOC'21

@SamikshaSankar Are you able to work on this issue, If not then it's fine, I can assign this issue to @jayant766

@SamikshaSankar are u working on it? its 21 today .. u said u will do it before 22nd ... kindly complete the issue by tomorrow or else it will go to @jayant766

@kanak22 yes u can assign to @jayant766

@jayant766 this issues goes to you,start working on it ... you have 5 days to complete it :)

I would like to work on this issue.

@jayant766 it's been 8 days u haven't gave any updates on this issue

@kanak22 Thanks for handling things very actively, This issue has to be re-assigned to @RituCs 👍🏽

@RituCs  any updates?

@RituCs any updates?

Sorry for the delay. I was busy for final sem exam.From tomorrow I will start working.Please give some time.Thanks!

okay u have 4 days :)


socket unix not allowed in constructor

I do not see a way to open a connection using a socket (unix).
It seems the constructor is closed to using hostname and port.
It is interesting to respect the use of a socket (allowed in mysqli).
You can also think changing the design to allow use of an externally created connection.
The component can delegate unto others, like an external framework, to host the top level configuration, handling of a connection-pool, redundancy or whatever new features appear.
So it is better suited for integration with others projects. To use this component as a thin abstraction layer on top of mysqli (connection).

Hey, thanks for the suggestion, @jferran95. I can definitely add socket as an option to the constructor. I think it might be better to make it into a key-value array now.
Can you please clarify your second point for what you're looking for in terms of design change?

Still testing. Need to evaluate first. But before that I saw a relevant issue with the design. This component takes the responsibility to open a connection. That is a huge no thanks. That is a sensitive feature. Due to security it is nice to hide. Another black box [component] will provide a connection. Dealing with user authentication, connection persitence, pooling, load balancing, targeting multiple databases (batch processes). This component in order to be simple, must give up on that responsibility.
For instance I modified it just for testing purposes (evaluation):
	public function __construct( $input_mysqli ) {
	    //mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
	    $this->mysqli = $input_mysqli;
	    $this->mysqli->set_charset( 'utf8mb4' );
	}

So a php-framework provides the connection. And this component works on top, as a mere wrapper.
Will have more insight about the design after using it for days.

Ah, ok, I understand you. Ya, I agree it would be better to use dependency injection. I'd be happy to make this change.


Console commands - allow to override command name

Add ability to override names of console commands bundled with phinx so that one is able to incorporate them in project's custom console
use Phinx\Console\Command;

$application = new \Symfony\Component\Console\Application();
// ...
// migrations command
$application->addCommands(array(
    new Command\Init("migration:init"),
    new Command\Create("migration:create"),
    new Command\Migrate("migration:migrate"),
    new Command\Rollback("migration:rollback"),
    new Command\Status("migration:status"),
    new Command\Breakpoint("migration:breakpoint"),
    new Command\Test("migration:test"),
    new Command\SeedCreate("migration:seed-create"),
    new Command\SeedRun("migration:seed-run"),
));
// ...
$application->run();

That way we get this:
$ ./console.php
Console Tool

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  breakpoint             Manage breakpoints
  help                   Displays help for a command
  list                   Lists commands
 migration
  migration:create       Create a new migration
  migration:init         Initialize the application for Phinx
  migration:migrate      Migrate the database
  migration:rollback     Rollback the last or to a specific migration
  migration:seed-create  Create a new database seeder
  migration:seed-run     Run database seeders
  migration:status       Show migration status
  migration:test         Verify the configuration file

instead of this
$ ./console.php
Console Tool

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  breakpoint   Manage breakpoints
  create       Create a new migration
  help         Displays help for a command
  init         Initialize the application for Phinx
  list         Lists commands
  migrate      Migrate the database
  rollback     Rollback the last or to a specific migration
  status       Show migration status
  test         Verify the configuration file
 seed
  seed:create  Create a new database seeder
  seed:run     Run database seeders

How about (new Command\SeedRun())->setName('custom:seed)?

Well passing name through constructor is cleaner. Argument passed through constructor that has no effect is not right.

Requires a new approach now after https://github.com/cakephp/phinx/pull/1588


Use only .near with existing latitude and longitude

Hi, I have a model already holding latitude and longitude with no address. How to use .near method to simply lookup by latitude and longitude?

Easiest way is probably to do this:
reverse_geocoded_by :latitude, :longitude

That will add the near method to the model.


Login/Register page

AuthForm.module.scss

Dont shorten  the classnames
Dont use _ to name the classes lets use camel case for consistence
Same for this one

Lets Restructure the file base system:

All React Components go to the components folder
In the components folder each component has a separate folder with the same name as the component (if there is a need for css put it in there also)
components that are going to be used multiple times go in the Shared folder
When making a page dont name it AuthPage --> just Auth

Css is looking great <3


Rework macosInstallPath/msiBuild linker variable

crc uses 2 different variables for macos/msi releases, with subtly different behaviour on the 2 platforms when the installer is used, and some code duplication.
This PR tries to address this.
Relates to: Issue #2656
Solution/Idea
This will introduce a single isInstaller linker variable, which will be used on the 2 platforms.
Proposed changes
List main as well as consequential changes you introduced or had to introduce.

The default networking mode is changed to be user mode on all platforms (it was already this way on macOS and Windows), see commit settings: Use user-mode networking by default on all platforms
It's no longer possible to change the networking mode on Windows installer builds. This is similar to what is done for macOS installer builds, see commit settings: Force use of user networking on Windows
IsMacosInstallPathSet()/IsMsiBuild() are replaced with IsInstaller()
GetMsiInstallPath()/GetMacosInstallPath() are replaced with InstallPath()

Items 1. and/or 2. can easily be removed without impacting the rest of the patch series if they are not desirable right now.
Testing
What is the bottom-line functionality that needs testing? Describe in pseudo-code or in English. Use verifiable statements that tie your changes to existing functionality.

check that after installation, crc is still able to properly use its misc binaries (helpers, trays, ..), and still work properly.

@cfergeau we need to update the e2e tests if we are switching the network mode to usermode for linux also.

@cfergeau I should separate https://github.com/code-ready/crc/pull/2661/commits/24a4e79e7c4219b11d504bdbf933bb2017b5d4f7 one to a different PR because here we are changing the network mode to user for Linux and that means our documents around remote https://crc.dev/crc/#setting-up-remote-server_gsg need to be updated.

@cfergeau we need to update the e2e tests if we are switching the network mode to usermode for linux also.

Yep, was looking into this. I'll first fix CI, then I'll see what needs to be done for default networking, don't be surprised if the follow-up iterations do nothing for default networking at first.