Traits Idea

Is your feature request related to a problem? Please describe.
I'm thinking about adding traits to the game. Some positive, some negative, but they should all affect gameplay in different ways. Although this isn't in BitLife, I'm considering adding it to this game.
Describe the solution you'd like
There should be different traits, some positive, some negative. They should be randomized when choosing "Random Life", and should be selectable when choosing "Custom Life". Also, two opposite traits should not be possible to receive at the same time.
I'm trying to come up with as many as I can. Please suggest traits in the comments and I may add them to this list.
Positive Traits:

Nerd: Makes it easier to increase smarts by doing activities
Cheerful: Makes it easier to increase happiness

Negative Traits:

Grumpy: Harder to get into a good mood, harder to stay in a good mood

Mixed Traits (both positive and negative elements)

Moody: Happiness changes more, and the changes in happiness (either up or down) are more intense

Describe alternatives you've considered
None

If you want to have many traits in this project. I suggest you check this wiki from The Sims 4 game.

Hope these can provide inspiration
https://eu4.paradoxwikis.com/Personalities
https://www.dwarffortresswiki.org/index.php/DF2014:Personality_trait

it would be good if you could learn traits by doing something, or select traits for your child/ren (for nature vs nurture).
i.e. you can be born a jock and die a nerd depending on how you go through life.
similar to bit life's sporting, acting, music strengths that make it easier to join the cheerleading / gymnastics / athletics school activities, or to learn acting or an instrument.
which, in turn make it easier to get a job as an athlete, actor, musician.
maybe doing lots of homework each year in school helps to gain the nerd trait > helps to get work in STEM careers / skip some uni
or lots of bullying in school makes it harder to get work that isn't crime, but makes crime work easier. maybe co-workers hate you and do what they can to get you fired (set you up and then report you to HR)

Jock trait
Actor
Musical
Bully
Natural born leader

it would be good if you could learn traits by doing something, or select traits for your child/ren (for nature vs nurture). i.e. you can be born a jock and die a nerd depending on how you go through life.
similar to bit life's sporting, acting, music strengths that make it easier to join the cheerleading / gymnastics / athletics school activities, or to learn acting or an instrument. which, in turn make it easier to get a job as an athlete, actor, musician.
maybe doing lots of homework each year in school helps to gain the nerd trait > helps to get work in STEM careers / skip some uni or lots of bullying in school makes it harder to get work that isn't crime, but makes crime work easier. maybe co-workers hate you and do what they can to get you fired (set you up and then report you to HR)

Jock trait (sports and fitness, gets more from runs/gym/martial arts + sports careers)
Actor (learn acting easily, gets happy easier but also gets sad easier (happy/sad drama face) + acting careers)
Musical (learn music/singing easier, people like you a little more, + musical jobs)
Bully (better at winning fights, people dislike you more, harder to keep a job, easier crime life & prison escape)
Natural born leader (quickly become leader of school activities/cliques, make your own clique, people are drawn to you & like you more, faster job promotion & raises

Sounds like a good idea
For now, I'll be implementing being able to learn the "Nerd" trait and then eventually I'll be able to add other learnable traits

Note that when learning a trait, conflicting traits are removed first before actually learning the trait
For example, if you wanted to learn Fast Worker while having the Slow Worker trait, you'd first have to lose Slow Worker before you could get Fast Worker.

That makes sense for conflicting traits to have a -1, 0, +1 scale

Next, I'm going to add a trait called Book Lover (you gain more happiness when going to the library) which has a small chance of being learned when visiting the library


Create file

Does this gem support creation of files? I'm having issues uploading files using
clubhouse.files.create(file: File.new(...))
{:code=>"400",  :status=>"Bad Request",  :content=>   {"message"=>"The request included invalid or missing parameters.",    "errors"=>{"file"=>["not", ["map?", "a-java.lang.String"]]}}}

@subclinical - I'll look into this.


Importing compiled framework results in errors.

I took the compiled frameworks from the C4iOS project, added them the Library > Frameworks and then linked them into a new project. (NOTE: I'm setting up a project that links libs so that I can recreate it as a template that we can load from an installer).
My main ViewController looks like:
import UIKit
import C4Core
import C4UI
import C4Animation

class ViewController: C4CanvasController {
    override func setup() {

    }
}

I get the following two errors:
'C4CanvasController' is unavailable: cannot find Swift declaration for this class
Method does not override any method from its superclass

Also, I receive the following warning when only linking the projects (i.e. not calling any classes or methods from them):
(null): Ld: warning: ld: warning: ignoring file /Library/Frameworks/C4Core.framework/C4Core, missing required architecture x86_64 in file /Library/Frameworks/C4Core.framework/C4Core (2 slices)ignoring file /Library/Frameworks/C4UI.framework/C4UI, missing required architecture x86_64 in file /Library/Frameworks/C4UI.framework/C4UI (2 slices)ignoring file /Library/Frameworks/C4Animation.framework/C4Animation, missing required architecture x86_64 in file /Library/Frameworks/C4Animation.framework/C4Animation (2 slices)

@aleph7 any thoughts?

How did you compile them? You need to go Product -> Archive

Yeah, archived then dragged them into Library > Frameworks, still no go.
Might be my project settings... Can you archive them and push your project settings?

Looks like copying to /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/ and /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/ is the way to go but I still get some error.

That actually works, just remember to include CoreAudio as well.

delete xcode 6.4, xcode 7.3-beta

delete library/developer (entire folder was something like 17GB, fyi)

install 6.4 from app store

create new iOS swift project

run in sim

quit xcode, sim

drop two sets of frames into Xcode

open project

import C4Core / C4UI (works)

C4CanvasController (doesn’t work)

add:

compiles!

run, crashes:

dyld: Library not loaded: @rpath/libswiftCoreAudio.dylib

  Referenced from: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/C4UI.framework/C4UI

  Reason: image not found

Tried deleting derived data and cleaning, still doesn’t work

Tried importing frameworks directly to project (via, v Linked Frameworks and Libraries) option, still doesn’t work

NOTE: still requires import call even w/ pointer to the right directory

Did you try adding it as an embedded framework?

i'd have to add both sim and os versions... will try

embedding works in the simulator

but, not on the device...

i tried embedding both sets of frameworks
i tried removing the set of simulator frameworks

fixed with: https://github.com/C4Framework/C4iOS/releases/download/1.0.0/C4-1.0.0.zip


Option to disable emoji translation

Simple emojis like 😭 get translated into rectangles when viewed from minecraft for me, I would rather disable translation altogether and just see :sob: so I know what was being said.

The only way you'd be able to disable it, is to set
#Convert Discord to MC, and MC to Discord Formatting
    formatting = true

to false.
Otherwise, you can install the Emojiful mod client side, and you will see the emojis

I do have emojiful actually, it converts :sob: just fine, but cant convert the unicode character.  Also I already tried disabling formatting, it disables formatting for things like bold/italic text and code blocks and such, but does nothing for emojis.

We got a similar report on discord earlier today.
It looks like discord started using unicode emojis, instead of the old style :smile: emojis, which emojiful is looking for. I'll have to find a work around to get the emojis working again, or just stripped completely.

BTW custom emojis still work, they are passed as :customemojiname: as expected.

Yup, it's just the built in discord emojis that's broken


[WIP] feat: Use laravel client and options

Still very WIP
Lumen and Laravel need to be >= 5.6 because of our requirement of PHP >= 7.1
It also currently uses a local overwrites in the PHP SDK to make it work.

Lumen and Laravel need to be >= 5.6

Are you sure about that? Couldn't you have older versions of Laravel under PHP 7.1 and be happy about that?


[BUG] Invalid calls to vSocketClose() when system bogged down and multiple TCP ports are closed all at once

Describe the bug
When the system is bogged down (cpu oversubscribed) and there are multiple TCP sockets open, and all TCP sockets are closed all at once, there are cases where extra calls to vSocketCLose() are performed on sockets that have already have been closed with bad socket data.
After much review of the environment and the message queue to the FreeRTOS-Plus-TCP IP task, narrowed down a bug in the lifetime management of the sockets in the socket layer.
Due to the use of: vSocketCloseNextTime, a socket may be both closed:

by the TCP layer calling vSocketCloseNextTime( pxSocket ), storing the pxSocket socket in the xSocketToClose global variable and then closed later by another call to vSocketCloseNextTime(NULL) which is called first thing in the prvIPTask(). While the second call:
User defined FreeRTOS_closesocket() - is performed by the user since the user still has a local store of the opened FreeRTOS_Socket_t.

Believe at some point in the tcp code a vTCPStateChange( pxSocket, eCLOSE_WAIT) is issued without intervention by the user.  The user also requests a FreeRTOS_closesocket() to terminate the socket, but by then, the socket has already performed the close.
Because vSocketClose() deletes it's resources, when a closed socket is closed again, a DataAbort interrupt is executed due to a Bad Address, and attempting to delete a list item twice.
Target

Development board: [e.g. Zynq]
Instruction Set Architecture: [ARM CortexA9]
IDE and version: VSCode + CMake
Toolchain and version: arm-none-eabi-gcc 10.3.1

Host

Host OS:  Ubuntu 18.04
Version: [e.g. Mojave 10.14.6]

To Reproduce

Unable to provide an example at this moment, but if you look at the code you can see this scenario is in fact possible.

Expected behavior
The Socket layer maintains a well known lifetime definition of all sockets created by the user, and ensures if at any point the socket is closed for internal reasons, it does not perform the same action again.
Screenshots
None
Wireshark logs
None
Additional context
Debug - additional messages from Close Execution:
vSocketClose: Caller name: 1315BCS
vSocketClose: pxSocket: 0x0036FDD0
vSocketClose: pxSocket.usLocalPort: 12121
Lost: Socket 12121 now has 0 / 5 children
FreeRTOS_closesocket[12121 to C0A80064ip:49305]: buffers 64 socks 4
______________________prvProcessIPEventsAndTimers: vSocketClose about to get called______________________
vSocketClose: Caller name: 12A184S
vSocketClose: pxSocket: 0x00308870
vSocketClose: pxSocket.usLocalPort: 12345
Lost: Socket 12345 now has 0 / 5 children
FreeRTOS_closesocket[12345 to C0A80064ip:49304]: buffers 64 socks 3
______________________prvProcessIPEventsAndTimers: vSocketClose about to get called______________________
vSocketClose: Caller name: 12A184S
vSocketClose: pxSocket: 0x0036FDD0
vSocketClose: pxSocket.usLocalPort: 12602
FreeRTOS_closesocket: xSocket: 0x0036FDD0
FreeRTOS_closesocket: xSocket.usLocalPort: 12602

Note that the vSocketClose is called twice on pxSocket 0x0036FDD0 - due to another socket's close being executed.
Where a dump of the callers is:
0x0012cfe0 vSocketClose(): FreeRTOS_Sockets.c, line 1550
0x001315bc vSocketCloseNextTime(): FreeRTOS_TCP_IP.c, line 126
0x0013d7c0 vCheckNetworkTimers(): FreeRTOS_IP_Timers.c, line 243
0x00129ffc prvProcessIPEventsAndTimers(): FreeRTOS_IP.c, line 290
0x00129fe8 prvIPTask(): FreeRTOS_IP.c, line 271

So the first close of the first socket is due to the vSocketCloseNextTime() and the second one is due to user request.  On the second close, a DataAbort occurs inside the uxListRemove function.

Hello @phelter, thank you for this report.
There is something I don't understand: when vSocketCloseNextTime() is called, the socket it still an orphan, it has not been passed to the application yet. Therefore it is obligatory and safe for the IP-task to call FreeRTOS_socketclose() (in a delayed manner).
This is where vSocketCloseNextTime() is called the first time:
if( ( eTCPState == eCLOSED ) ||
    ( eTCPState == eCLOSE_WAIT ) )
{
    if( ( pxSocket->u.xTCP.bits.bPassQueued != pdFALSE_UNSIGNED ) ||
        ( pxSocket->u.xTCP.bits.bPassAccept != pdFALSE_UNSIGNED ) )
    {
        if( pxSocket->u.xTCP.bits.bReuseSocket == pdFALSE_UNSIGNED )
        {
            vSocketCloseNextTime( pxSocket );
        }
    }
}

So the TCP status must be eCLOSED or eCLOSE_WAIT, it has not been passed to the application, and it is not a reuseable socket.
The time between the following statements is very small :
    vSocketCloseNextTime( pxSocket );
    ...
    vSocketCloseNextTime( NULL );

    /* Now the IP-task will block again */
    xQueueReceive( xNetworkEventQueue, ...);

I would be curious to see/understand your TCP-related code, especially the API calls, and the call to FreeRTOS_closesocket().
Why does your code call FreeRTOS_closesocket(), what has happened just before that?
In the PR you show a sequence of events in a log. Do you have the same type of log without applying the patch?
And just curiosity: what priorities have you assigned to the IP-task and to the task that calls TCP API's?

The use case is:
There are two server sockets that are created - each in their own task defined by prvConnectionListeningTask and with different ports.
The first thing that gets executed within each of the tasks is vCreateTCPServerSocket
void prvConnectionListeningTask( void *pvParameters )
{
    struct freertos_sockaddr xClient;
    Socket_t                 xListeningSocket = FREERTOS_INVALID_SOCKET;
    Socket_t                 xConnectedSocket = FREERTOS_INVALID_SOCKET;
    socklen_t xSize = sizeof( xClient );
    serverTaskInfo_t        *pxServerTaskInfo = NULL;

    pxServerTaskInfo = ( serverTaskInfo_t* ) pvParameters;

    xListeningSocket = vCreateTCPServerSocket(pxServerTaskInfo->portNum);
    FreeRTOS_listen( xListeningSocket, pxServerTaskInfo->connectionBacklog );

    for( ;; )
    {
        xConnectedSocket = FreeRTOS_accept( xListeningSocket, &xClient, &xSize );
        configASSERT( xConnectedSocket != FREERTOS_INVALID_SOCKET ); // NOLINT performance-no-int-to-ptr

        xTaskCreate( pxServerTaskInfo->serverHandlerTask,
                     pxServerTaskInfo->taskName,
                     pxServerTaskInfo->stackSize,
                     ( void * ) xConnectedSocket,
                     pxServerTaskInfo->taskPriority,
                     NULL );
    }
}

static Socket_t vCreateTCPServerSocket( uint16_t pPortNum )
{
    struct freertos_sockaddr xBindAddress;
    Socket_t                 xListeningSocket = FREERTOS_INVALID_SOCKET;
    static const TickType_t xReceiveTimeOut = portMAX_DELAY;

#if( ipconfigUSE_TCP_WIN == 1 )
    WinProperties_t xWinProps;

    xWinProps.lTxBufSize = ipconfigTCP_TX_BUFFER_LENGTH;
    xWinProps.lTxWinSize = ipconfigTCP_WIN_SEG_COUNT;
    xWinProps.lRxBufSize = ipconfigTCP_RX_BUFFER_LENGTH;
    xWinProps.lRxWinSize = ipconfigTCP_WIN_SEG_COUNT;
#endif /* ipconfigUSE_TCP_WIN */

    xListeningSocket = FreeRTOS_socket( FREERTOS_AF_INET, FREERTOS_SOCK_STREAM, FREERTOS_IPPROTO_TCP );
    configASSERT( xListeningSocket != FREERTOS_INVALID_SOCKET );

    FreeRTOS_setsockopt( xListeningSocket, 0, FREERTOS_SO_RCVTIMEO, &xReceiveTimeOut, sizeof( xReceiveTimeOut ) );

#if( ipconfigUSE_TCP_WIN == 1 )
    FreeRTOS_setsockopt( xListeningSocket, 0, FREERTOS_SO_WIN_PROPERTIES, ( void * ) &xWinProps, sizeof( xWinProps ) );
#endif /* ipconfigUSE_TCP_WIN */

    xBindAddress.sin_port = FreeRTOS_htons( pPortNum );
    FreeRTOS_bind( xListeningSocket, &xBindAddress, sizeof( xBindAddress ) );
    return xListeningSocket;
}

As you can see the listening socket spawns an independent task for each accepted connection.
The function that is passed as: pxServerTaskInfo->serverHandlerTask is:
void vServerConnectionInstance( void *pvParameters )
{
    Socket_t                xSocket = FREERTOS_INVALID_SOCKET;
    static char cRxedData[ TCP_RX_DATA_BUFFER_SIZE ];
    CR02BaseType_t          lBytesReceived  = 0;
    static const TickType_t xReceiveTimeOut = pdMS_TO_TICKS( CONFIG_SERVER_TCP_TIMEOUT_MS );
    static const TickType_t xSendTimeOut =    pdMS_TO_TICKS( CONFIG_SERVER_TCP_TIMEOUT_MS );

    /* The socket has already been created and connected before
    being passed into this RTOS task using the RTOS task's parameter. */
    xSocket = ( Socket_t ) pvParameters;

    FreeRTOS_setsockopt( xSocket, 0, FREERTOS_SO_RCVTIMEO, &xReceiveTimeOut, sizeof( xReceiveTimeOut ) );
    FreeRTOS_setsockopt( xSocket, 0, FREERTOS_SO_SNDTIMEO, &xSendTimeOut, sizeof( xSendTimeOut ) );
    for( ;; )
    {
        lBytesReceived = FreeRTOS_recv( xSocket, &cRxedData, TCP_RX_DATA_BUFFER_SIZE, 0 );

        if( lBytesReceived > 0 )
        {
            prvProcessRXConfigData( xSocket, cRxedData, (size_t)lBytesReceived );
        }
        else if( lBytesReceived == 0 )
        {
        }
        else
        {
            FreeRTOS_shutdown( xSocket, FREERTOS_SHUT_RDWR );
            break;
        }
    }

    while( FreeRTOS_recv( xSocket, &cRxedData, TCP_RX_DATA_BUFFER_SIZE, 0 ) >= 0 )
    {
        vTaskDelay( pdMS_TO_TICKS( 250 ) );
    }

    FreeRTOS_closesocket( xSocket );

    vTaskDelete( NULL );
}

This is the only place the FreeRTOS_closesocket() is used in the entire code base, and it is only used on the connection sockets.  There is no FreeRTOS_closesocket() performed on the listening sockets as they are assumed to be enabled forever (until reset).  And based on the logs only occurs when the LAST connection socket is being closed.
The failure happens then because these are not REUSE_SOCKET's and some internal state of a socket in the TCP layer is being used to decide the socket layer lifetime.  The changes provided ensure that the socket layer maintains it's own knowledge of the lifetime of a socket and acts accordingly (regardless of the TCP layer's state definition.

Thank you for the code and your comments.
Your assumption about a possible race condition does not seem correct to me.
As long as xSocketToClose is set, it is impossible to call vSocketClose() from another task:
  xQueueReceive()                    // returns 'eNetworkRxEvent'
  vSocketCloseNextTime( pxSocket );  // xSocketToClose = pxSocket

  // A competing task calls 'FreeRTOS_closesocket()', it must wait

  vSocketCloseNextTime( NULL );      // pxSocket is closed, xSocketToListen = NULL

  xQueueReceive();                   // returns 'eSocketCloseEvent'
  vSocketClose();                    // Because a 'eSocketCloseEvent' was received

Between two calls to xQueueReceive(), only one message will be handled, no task can come in-between.
The buffer parameter to FreeRTOS_recv() was preceded by an ampersand.:
     static char cRxedData[ TCP_RX_DATA_BUFFER_SIZE ];
-    lBytesReceived = FreeRTOS_recv( xSocket, &cRxedData, TCP_RX_DATA_BUFFER_SIZE, 0 );
+    lBytesReceived = FreeRTOS_recv( xSocket, cRxedData, TCP_RX_DATA_BUFFER_SIZE, 0 );

which may lead to data corruption.
I don't know if you it is easy to reproduce the problem, but then I would rewrite vSocketClose() to just print that it is being called and show the socket pointer. Also, I would be curious about these flags at the time vSocketClose() is called:
  bPassAccept : 1,   /**< when true, this socket may be returned in a call to accept() */
  bPassQueued : 1,   /**< when true, this socket is an orphan until it gets connected
                      * Why an orphan? Because it may not be returned in a accept() call until it
                      * gets the state eESTABLISHED */
  bReuseSocket : 1,  /**< When a listening socket gets a connection, do not create a new instance but keep on using it */

I had some more minor remarks about the code and attach them here: demo_code.zip
One remark shutdown() does not have to be called by a TCP server, unless it wants to take the initiative to disconnect from a TCP client.
And also: an invalid socket is defined as a socket that is either NULL or FREERTOS_INVALID_SOCKET.
Could you post the FreeRTOS_IPConfig.h that you used for your project? The function xSocketValid() tests for both values.

Hello @htibosch ,
While I agree with you about the use of the &cRxedData  vs cRxedData is misleading if you prefer implied conversion of arrays to a pointer to their array type, it is not an issue because the array is defined above as an array of char of fixed size and the data is stored in the first location of the array.
Please see: ISO/IEC 98/99 section <IP_ADDRESS> - paragraph 2.
And the explanation here
This means the &cRxedData translates to a pointer to head of the type char[TCP_RX_DATA_BUFFER_SIZE], which also happens to be a pointer to the first element of the array. The difference between the two:
Currently implemented: &cRxedData -> pointer to a char[TCP_RX_DATA_BUFFER_SIZE] - which is the first char of that buffer.
What you proposed cRxedData -> pointer to a char through implicit conversion - which is also the first char of that buffer.
So it is not this.
All I know is when the code provided in PR #571 - which is explicitly checking the lifetime of a socket is put in place, this issue no longer happens.
As mentioned the sockets returned to the user from FreeRTOS_accept() API are sockets that have been created and provided to the user.  It is also acceptable to close these clientSockets at any time using FreeRTOS_closesocket() - even after the far end may have closed the socket.  I believe that the far end closing the socket before the client does is also a possible cause for the error.
It is very difficult to prove that the state of a TCP socket is correct or will only terminate a socket NOT provided back to the user.  However, the fact that the logs provided in the original description show that the same socket is closed multiple times - (once by user, and once internally) should be sufficient proof that there is a lifetime issue in this code and that the separation of the act of closing and the act of destroying a socket are two independent actions unless the close is requested by the user.
I have provided the necessary info and fix for this issue which has been proven on our machine to work and operate.  If you require further proof the issue exists, I suggest creating a unit test or proof that a socket returned by FreeRTOS_accept() is never closed internally unless requested by the user via FreeRTOS_closesocket().  My belief is the existence of the vSocketCloseNextTime() shows this proof false.

@htibosch

One remark shutdown() does not have to be called by a TCP server, unless it wants to take the initiative to disconnect from a TCP client.

Yes I am aware. I did not use shutdown() in any of the examples provided associated with this particular bug and have used the Berkley API for over 20 years now.

And also: an invalid socket is defined as a socket that is either NULL or FREERTOS_INVALID_SOCKET. The function xSocketValid() tests for both values.

Yes I am aware. And I fixed several places in the PR #571 - where the socket received by the IPTask event queue was not checking for both NULL OR FREERTOS_INVALID_SOCKET.

Could you post the FreeRTOS_IPConfig.h that you used for your project?
See Attached: FreeRTOSIPConfig.zip

Hi @phelter, mind you that I am ( we are ) very grateful that you came up with this issue, and that you spent so much time on it.
About &cRxedData vs cRxedData : I responded too quickly. Your code is of course correct.
And about my remark about shutdown(): don't take it personal. One of my tasks (on the FreeRTOS forum) is to give informations to developers. And sometimes I tell things that people already know.
Before we make a reparation or a patch that protects against unwanted behaviour, I would like to understand why a socket can "have two owners": the IP-task and the application.
I would like to see a patch that prevents this, in stead of protecting vSocketClose() against "bad behaviour".
About Priorities:
The FreeRTOS+TCP library was written with the silent assumption that the IP-task has a higher priority than any of its users. In fact, we have always recommended this scheme:
Higher : Network Interface (niEMAC_HANDLER_TASK_PRIORITY)
Normal  : IP-task (ipconfigIP_TASK_PRIORITY)
Lower : any task that makes use of +TCP
In FreeRTOS_accept(), you can see that the user task is altering the contents of a socket:
vTaskSuspendAll();
{
    if( pxSocket->u.xTCP.bits.bReuseSocket == pdFALSE_UNSIGNED )
    {
        pxClientSocket = pxSocket->u.xTCP.pxPeerSocket;
    }
    else
    {
        pxClientSocket = pxSocket;
    }

    if( pxClientSocket != NULL )
    {
        pxSocket->u.xTCP.pxPeerSocket = NULL;

        /* Is it still not taken ? */
        if( pxClientSocket->u.xTCP.bits.bPassAccept != pdFALSE_UNSIGNED )
        {
            pxClientSocket->u.xTCP.bits.bPassAccept = pdFALSE;
        }
        else
        {
            pxClientSocket = NULL;
        }
    }
}
( void ) xTaskResumeAll();

This is safe to do because the scheduler is temporarily suspended by calling vTaskSuspendAll().
When the user task has a higher priority than the IP-task, we can:

Add a new API for accept() to guarantee a strict sequential order of events
Let the IP-task suspend the scheduler at certain places
Make it mandatory to assign a higher priority to the IP-task (with checks).

The cause
I think that the following happens:
For an unknown (but likely legitimate) reason, the IP-task puts the socket in status eCLOSED or eCLOSE_WAIT, and orders the deletion of it by calling vSocketCloseNextTime().
The (listening) parent socket still has a reference to the child socket in xTCP.pxPeerSocket.
The user application calls FreeRTOS_accept() and finds a new client socket in xTCP.pxPeerSocket. It quickly discovers that the socket is already closed, and so it calls FreeRTOS_closesocket(), which leads to an exception.
In a solution, I think that xTCP.pxPeerSocket of the parent should be cleared as soon as the IP-task wants to delete the socket.
A TCP connection can be closed because of the following reasons:
eCLOSED:

A TCP/RST packet was received.

eCLOSE_WAIT:

Malloc failed.
Closing because non-activity ( HANG protection ).
FIN stage ready ( graceful closure ).
Unexpected TCP flags received.
Transmission times out after 3 attempts.

Question 1, do you have any idea why the sockets were put into eCLOSED or eCLOSE_WAIT state?
Question 2, could you describe the steps that must be taken to reproduce the problem?
Question 3, you wrote "When the system is bogged down (cpu oversubscribed)"
What are the consequences for the 2 servers when:
IP-task : - is at priority 14 - (configMAX_PRIORITIES - 2) (ipconfigIP_TASK_PRIORITY)
Server A: - is at priority 14 - (configMAX_PRIORITIES - 2)
Server B: - is at priority 1 - (tskIDLE_PRIORITY + 1)
Did they come to a stop during the over-subscription?
Thanks

Hello @htibosch, thank you for your response.
Regarding:

And about my remark about shutdown(): don't take it personal. One of my tasks (on the FreeRTOS forum) is to give informations to developers. And sometimes I tell things that people already know.

I did not take it personal; however, it would be appreciated that bugs of this nature, are treated guilty until proven innocent rather than innocent until proven guilty by the maintainers of the code base.  It is a very serious issue and with proof provided that using the API provided in a valid and acceptable way leads to a catastrophic result of memory use after being freed.  I have spent a significant number of hours identifying, explaining, resolving and testing the issue and the hope was that the remainder of the work involved in supporting this would be taken on by the maintainers of the FreeRTOS-Plus-TCP repo.

Before we make a reparation or a patch that protects against unwanted behaviour, I would like to understand why a socket can "have two owners": the IP-task and the application.

A socket does not have 2 owners (construction and destruction in C++ terms), however it does have 2 actors that can close a socket - the user app of the server - in this case is also the owner of the socket on the server side, and the client which does so via a close request from the far end and then the IPTask acts as a proxy for the client on the server side to complete this action.  The IPTask is allowed to close the socket, but it is not allowed to destroy the socket as this is the job of the 1 owner.

Question 1, do you have any idea why the sockets were put into eCLOSED or eCLOSE_WAIT state?

Without confirmation - my current theory is:
A socket is returned from FreeRTOS_accept()

the pxSocket is Valid, not a ReuseSocket, eTCPState is Listening, and the peerSocket is not Null.
this results in

    pxClientSocket = pxSocket->u.xTCP.pxPeerSocket;
    ...
    pxSocket->u.xTCP.pxPeerSocket = NULL;
    ...
    pxClientSocket->u.xTCP.bits.bPassAccept = pdFALSE;
    ( void ) xSendEventStructToIPTask( &xAskEvent, portMAX_DELAY );
    return pxClientSocket;

At this point the pxClientSocket is returned to the user on the server side with:
pxClientSocket->u.xTCP.bits.bPassAccept = pdFALSE_UNSIGNED
pxClientSocket->u.xTCP.bits.bPassQueued = ??
Due to the way the u.xTCP.bits.bPassAccept and bPassQueued are being used and changed, their state may not correctly reflect the actual state of the TCP socket.
These bits are consumed in the following functions in the associated ways:
vTCPStateChanged - (Read/Modify/Write) on pre-existing sockets that have been returned to a user
prvTCPSocketCopy - (Write) on new sockets that have not been returned to a user (OK).
prvHandleListen - (Write) on pre-existing sockets
FreeRTOS_accept - (Read/Modify/Write) on socket that has not been returned to a user (OK).
prvTCPStatusAgeCheck - (Read) - pre-existing socket
xTCPCheckNewClient - (Read) - pre-existing socket
vSocketSelect - (Read)- pre-existing socket
prvTCPSetSocketCount - (Read) - pre-existing socket.
vTCPStateChanged is called in both the calls associated with the API - eg: FreeRTOS_listen()  and in private functions which I believe are in the IPTask - but not confirming all of this.  This means that multiple Tasks have the ability to read/modify/write this data without the proper mutex locking scheme that is used to ensure state is consumed in an atomic and protected manner.
The code is assuming these to be atomic and a common state - i.e. the use of both together in an if statement - we have the correct knowledge of PassQueued and PassAccept - as a combined state.
eg: the case where:
            if( ( pxSocket->u.xTCP.bits.bPassQueued != pdFALSE_UNSIGNED ) ||
                ( pxSocket->u.xTCP.bits.bPassAccept != pdFALSE_UNSIGNED ) )

This translates into two actions: confirming bPassQueued != false and bPassAccept != false - in between them they can be interrupted by another thread that changes both to be false or true, which means you do not have the combined state.  A similar case can be made for checking the value and then changing it, or writing both values together.
The solution to this is to either:

use a semaphore-mutex lock on all read or read/modify/write or write actions of these states of the Socket_t,  this would require a mutex per Socket_t
disable interrupts as you have done in the one spot of the FreeRTOS_accept() around all access actions of these state bits using vTaskSuspendAll() and vTaskResumeAll()

Question 2, could you describe the steps that must be taken to reproduce the problem?

Unfortunately no, I am working remotely helping out a team that is performing the debugging on the device itself.  I believe I have provided the necessary info to reproduce, but I cannot share all of the code to reproduce the issue.

Question 3, you wrote "When the system is bogged down (cpu oversubscribed)"
What are the consequences for the 2 servers when:
IP-task : - is at priority 14 - (configMAX_PRIORITIES - 2) (ipconfigIP_TASK_PRIORITY)
Server A: - is at priority 14 - (configMAX_PRIORITIES - 2)
Server B: - is at priority 1 - (tskIDLE_PRIORITY + 1)
Did they come to a stop during the over-subscription?

No I don't believe so - they are all being serviced, just not necessarily very often due to other tasks in the system.

Hello @phelter, thank you for this report.
Apologies for the long wait.
We recently encountered a few scenarios where multiple socket free are observed.
The scenario is something like this:
If the server task calling FreeRTOS_accept runs at a priority lower than the IP task’s priority, we observe a double free of socket leading to memory corruption when a RST is received quickly after the connection is established. Here is the sequence of steps leading to double free -

When a connection is received, this line sets the event flag so that server task can return from FreeRTOS_accept call - https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/dev/IPv6_integration/source/FreeRTOS_TCP_IP.c#L347
Since the server task’s priority is lower than the IP task, it does not run immediately.
The IP task continues and sets u.xTCP.bits.bPassAccept as true here - https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/dev/IPv6_integration/source/FreeRTOS_TCP_IP.c#L380
The client sends RST and this line determines that the socket is orphaned because u.xTCP.bits.bPassAccept is true and calls vSocketCloseNextTime  - https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/dev/IPv6_integration/source/FreeRTOS_TCP_IP.c#L439
The next run of IP task calls vSocketCloseNextTime with NULL and deletes the socket – https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/dev/IPv6_integration/source/FreeRTOS_IP_Timers.c#L310
When IP task is no longer ready to run, the server task returns from the FreeRTOS_accept call and eventually calls FreeRTOS_closesocket leading to double free of the socket.

Please suggest if your observation is something like this.

We have this change https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/pull/705 for the above observation. Please check if this helps solving your scenario as well.

Closing this issue as a probable fix is available.


Navbar

Changing colour when scroll
adding padding property(add more space)
Anchor a navbar

please assign me @shriya030

It's already changing color when scroll.
Can you explain the other two points?

@SamikshaSankar Great! Go ahead!

Can i work on this issue?


[BACKLOG-21888] - step combo should be sorted by name

@pentaho/ackbar maybe doesn't need wingman??

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -Dsurefire.runOrder=alphabetical -B -fn -f 'pom.xml' -pl 'ui' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'ui' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'ui' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  ui/src/main/java/org/pentaho/di/ui/trans/step/BaseStreamingDialog.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: <0.1% (click to expand)
org.pentaho.di.trans.steps.salesforceupsert.SalesforceUpsertMeta

Instruction Change: -0.1% :small_red_triangle_down:

@pentaho/ackbar ready for review


--color is not enabled by default

Hi! Thanks for the project!
According to this t here: https://github.com/wbolster/emacs-python-pytest/blob/master/python-pytest.el#L139 and to the magit-popup manual, --color should be enabled by default, but apparently it's not. Am I missing something or it's a bug somewhere in emacs-python-pytest or in magit-popup?

hmm, seems this package is not to blame, since as you said it's supposed to be on by default. do you have settings in our init.el (also check what Customize did)?


Remove additional margin/padding of the code blocks

Fixes: https://github.com/minio/gluegun/issues/93

I am having the same rake issue here. How are you building?


Box Plots

See slack

I'd like to show A/B test results with confidence intervals, which would require box plots as a component type, similar to what's showing in this article.

https://www.sama.com/blog/experiment-driven-development-part-3/

There's a few ways we can set this up - the chart could accept pre-calculated data to create the boxes (i.e. you pass in the min, max, ranges yourself) or the chart can calculate everything when you pass in a series of numbers.
If we go with the latter, there's an ECharts utility function called prepareBoxplotData shown in this example here:
https://codepen.io/sjcobb/pen/GwYvKP

I've been able to pull together a very rough initial box plot component with hardcoded data:

Implementation Challenges

Importing the prepareBoxplotData function from echarts - I keep getting errors on this - either "not a function" or "cannot use import outside of a module"
Handling horizontal vs. vertical orientation with swapXY - this will take some extra thinking since the data structure is different from a normal chart
Passing group names to the x-axis is difficult

the chart could accept pre-calculated data to create the boxes (i.e. you pass in the min, max, ranges yourself) or the chart can calculate everything when you pass in a series of numbers.

my 2c.
I think supplying their own ranges for statistical significance is probably preferable to start, despite being a slightly worse interface.

You don't have to use the standard IQR, you can use whatever indication of significance they want.
You can pass in a small table, rather than pushing a large table + a client side JS calculation.

I think post #993 we could do the IQR calc in ddb/arrow performantly on a fairly large table, and offer it up as an option, but that's easier to add at some point if we start w/ a component that just creates the boxplot from the range arguments.


[Update] - Color modifiers (Pro) | Values Plugin

- [ ] Technical review
- [ ] Style Dictionary review
- [x] Initial doc created

Doc is here! Make sure you are looking at main.


Generated classes create conflicts with InternalsVisibleTo

Using the 3.0 b2 msbuild tasks, I see this:
C:\Users\Oren\Source\Git\MetroLog\MetroLog.WP8\obj\Release\GitVersionTaskAssemblyInfo.g.cs(8,12,8,23): warning CS0436: The type 'ReleaseDateAttribute' in 'C:\Users\Oren\Source\Git\MetroLog\MetroLog.WP8\obj\Release\GitVersionTaskAssemblyInfo.g.cs' conflicts with the imported type 'ReleaseDateAttribute' in 'MetroLog, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=ba4ace74c3b410f3'. Using the type defined in 'C:\Users\Oren\Source\Git\MetroLog\MetroLog.WP8\obj\Release\GitVersionTaskAssemblyInfo.g.cs'.

Problem is that the ReleaseDateAttribute and GitVersionInformation classes are created in the root namespace, so they'll conflict with friend access.
Proposal:
Put the attribute in a namespace underneath the assembly name.
I.e., for an assemlby Foobar.Frob:
namespace Foobar.Frob {
...
}

@SimonCropp, thoughts?

Dont object. But how bigger "greaking" change is this?

As these classes are generated at compile-time and included, how many people have references to those types?
I'd think it'd be more of a breaking change if it was generated on included somehow in VS so developers could use those types in their code directly?

well either way we r in v3beta so i say lets do it. @onovotny want to do a PR?

Wish I could, I just don't have the bandwidth right now :/

Should we also add a CompilerGeneratedAttribute too?


Support deprecated server.urls for CF

Description
Need to add support for --server.url to specify the url
Quality checklist

[ ] Your code complies with our Coding Style.
[ ] You've updated unit and/or integration tests for your change, where applicable.
[ ] You've updated documentation for your change, where applicable.
If your change affects other repositories, such as Documentation, Samples and/or MainSite, add linked PRs here.
[ ] There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.
[ ] You've added required license files and/or file headers (explaining where the code came from with proper attribution), where code is copied from StackOverflow, a blog, or OSS.

/azp run Cleanup-Code

/azp run Steeltoe.All

SonarCloud Quality Gate failed.
  0 Bugs   0 Vulnerabilities   0 Security Hotspots   0 Code Smells
 0.0% Coverage  0.0% Duplication

SonarCloud Quality Gate failed.
  0 Bugs   0 Vulnerabilities   0 Security Hotspots   0 Code Smells
 0.0% Coverage  0.0% Duplication

I do not think this is correct - running locally I get this:

/azp run Cleanup-Code

/azp run Steeltoe.All

SonarCloud Quality Gate failed.
  0 Bugs   0 Vulnerabilities   0 Security Hotspots   0 Code Smells
 0.0% Coverage  0.0% Duplication

SonarCloud Quality Gate failed.
  0 Bugs   0 Vulnerabilities   0 Security Hotspots   0 Code Smells
 0.0% Coverage  0.0% Duplication

I do not think this is correct - running locally I get this:

You're right, something is broken with Sonar Cloud's code coverage report in this branch (seems release/3.2 is working fine) - should be OK to ignore that check for right now

/azp run Cleanup-Code

/azp run Cleanup-Code

/azp run steeltoe.all

/azp run Steeltoe.All

/azp run Steeltoe.All


BlotTacToe-spageektti

[x] I have read the steps to getting a blot

[x] I am submitting art that...

[x] is algorithmically generated (will change each time the program is run)
[x] is drawable on a blot (fits in the work area & doesn't overlap too much)
[x] is original (not copied from somewhere else)
[x] doesn't call Math.random() (See the documentation on randomness)

[ ] Optional, if you used a tutorial or based your art on something else, please include the link here:

[ ] Optional, if you remixed this from something else, mention it here:
I didn't use any code from another project, but the idea was inspired by the Blotteships project.

Seeing as this hasn't been updated in 2 weeks, I'm going to close the PR for now. You're free to make a new one in the future with the same artwork if you'd like!


promtool check config complains about missing region in EC2 SD config

Use case. Why is this important?
I want to validate my prometheus configuration file
Bug Report
What did you do?
I run promtool check config against my prometheus.yml and got an error saying:
Checking packer/files/prometheus/config/prometheus.yml
  FAILED: parsing YAML file packer/files/prometheus/config/prometheus.yml: EC2 SD configuration requires a region

What did you expect to see?
I expected to see no errors as not having a region in the EC2 SD configuration is supported. Per the documentation: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#ec2_sd_config
# The AWS region. If blank, the region from the instance metadata is used.
Environment

System information:
Linux 4.15.0-65-generic x86_64

Prometheus version:

prometheus, version 2.12.0 (branch: HEAD, revision: 43acd0e2e93f9f70c49b2267efa0124f1e759e86)
  build user:       root@7a9dbdbe0cc7
  build date:       20190818-13:53:16
  go version:       go1.12.8

Prometheus configuration file:

global:
  scrape_interval: 10s

rule_files:
  - 'alerts/*.yml'

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093

scrape_configs:
  - job_name: 'prometheus'
    ec2_sd_configs:
      - port: 9090
    relabel_configs:
      - source_labels: [__meta_ec2_tag_Name]
        regex: prometheus
        action: keep
      - source_labels: [__meta_ec2_tag_Name]
        target_label: instance
      - source_labels: [__meta_ec2_tag_Environment]
        target_label: environment

The reason is that the code deserializing the YAML data queries the EC2 metadata service to get the region thus it will fail if promtool isn't executed from an EC2 instance. One could argue that it shouldn't be done at this stage.
https://github.com/prometheus/prometheus/blob/53ea6d63901b96a13bb79ff598c96af4a979adce/discovery/ec2/ec2.go#L91-L102

Is it possible to add a workaround such as passing the region via a CLI flag? For my use case I want to validate the configuration before building our Prometheus AMI via pre-commit hooks.
Right now I'm able to validate my Alertmanager configuration and Prometheus alert rules so this would be a very nice to have for our needs.

The only thing I have come up with to solve this problem is to run a local webserver on <IP_ADDRESS> (on localhost interface) and have it serve an availability zone on the endpoint.

We went through this issue in our bug scrub and we're not sure how to best deal with this, one approach is to move this check out of the config check, and maybe print a warning. Pmaybe because the semantics are not obvious.

I would move the check outside of the configuration check. A small warning mentioning that no region is defined and maybe a link to the ec2_sd_config would be useful in my opinion @gouthamve

That's pretty close to silently failing though.

How about adding the option to specify the region when invoking promtool check config. If no region is specified by the user then fail like we do right now @brian-brazil

Can't you specify it with an env variable in this case?

How @roidelapluie ? I don't see any mentions of env variables on https://prometheus.io/docs/prometheus/latest/configuration/configuration/#ec2_sd_config

I have checked the code and while we could possibly get the token from Env as a side effect of the imports, we explicitely check for a region indeed.

Should we close this issue then? @roidelapluie

No, this feature request is valid. We should be able to validate the file. I will comment me in a few hours.

Not sure if this is related, but I have a region defined in my configuration and am getting the same error re: requiring a region.
- job_name: 'flower'
  ec2_sd_configs:
    - region: 'us-west-2'
    - port: 5555
    - filters:
      - name: 'env'
      - values: 'celery'

Not sure if this is related, but I have a region defined in my configuration and am getting the same error re: requiring a region.
- job_name: 'flower'
  ec2_sd_configs:
    - region: 'us-west-2'
    - port: 5555
    - filters:
      - name: 'env'
      - values: 'celery'

Your configuration is invalid. Please see:
- job_name: 'flower'
  ec2_sd_configs:
    - region: 'us-west-2'
      port: 5555
      filters:
      - name: 'env'
        values: 'celery'

Any updates on this? I ran into the same issue when starting up Prometheus on a IMDSv2 enabled EC2 instance.

Any updates on this? I ran into the same issue when starting up Prometheus on a IMDSv2 enabled EC2 instance.

What we should do here is move this to inside the SD. We shouldn't be making network calls at the parsing a configuration file stage.

What we should do here is move this to inside the SD. We shouldn't be making network calls at the parsing a configuration file stage.

Any updates on this? I ran into the same issue when starting up Prometheus on a IMDSv2 enabled EC2 instance.

Is your issue with prometheus or promtool? Are you able to provide more details and open a new issue if the problem is not the same as the one in this issue. Thanks.

@roidelapluie Hey. thanks for coming back to me. I've got my problem solved. Although it's the same issue as @guidodobboletta's, my one is caused by wrong syntax. However, the message is misleading...
❌
    ec2_sd_configs:
      - region: ap-southeast-2
      - filters:
        - name: "tag:aws:cloudformation:stack:name"
          values:
            - io-210-imds-prometheus*

✅
    ec2_sd_configs:
      - region: ap-southeast-2
        filters:
          - name: "tag:aws:cloudformation:stack:name"
            values:
              - io-210-imds-prometheus*

Any updates on this? I ran into the same issue when starting up Prometheus on a IMDSv2 enabled EC2 instance.

Is your issue with prometheus or promtool? Are you able to provide more details and open a new issue if the problem is not the same as the one in this issue. Thanks.

@roidelapluie Hey. thanks for coming back to me. I've got my problem solved. Although it's the same issue as @guidodobboletta's, my one is caused by wrong syntax. However, the message is misleading...
❌
    ec2_sd_configs:
      - region: ap-southeast-2
      - filters:
        - name: "tag:aws:cloudformation:stack:name"
          values:
            - io-210-imds-prometheus*

✅
    ec2_sd_configs:
      - region: ap-southeast-2
        filters:
          - name: "tag:aws:cloudformation:stack:name"
            values:
              - io-210-imds-prometheus*

Hello from the bug scrub.
This still seems to be a valid issue, preventing automatically validating configs with promtool. To avoid confusion, we marked all the comments that are triggered by actually invalid Yaml files as off-topic.
The bottom line is that we have to find a way to validate the file without making a network call.


\pi<CR> returns πþX instead of π

Typing \pi<CR> returns πþX when it should return π. This does not happen with other symbols I tested.

This is with the latex_symbols source. @hrsh7th I tried to debug this but I wasn't able to figure out what is going on. I'm hoping maybe you might have some insight. You can close this if you think it's definitely not related to nvim-cmp.
Here's the same issue on the other repository: https://github.com/kdheepak/cmp-latex-symbols/issues/2

Thank you. This issue is very insightful. I've fixed.

Wow! Thanks for the quick fix! Works great! And thank you for all your work on this! I think using the LSP completion spec for the autocomplete is a good idea :) It should be very flexible.


Dropdown is broken with current alpine.js version

This is a regression. Alpine.JS update to 3.13.6 broke PetalComponents.Dropdown. In the meantime an update to Alpine.JS seems to have fixed this issue, but the issue just reappeared with the latest alpine.js update. Can we update the compent to work reliably with 3.13.6 and 3.14.6
@atomkirk previously described the issue here: https://github.com/alpinejs/alpine/discussions/4075

I did some testing. It seems that the latest version that works is 3.14.3.
Looking at 3.14.4 onwards, there seems to be a change in Alpine.js that prevents this code from doing its thing:
let liveSocket = new LiveSocket("/live", Socket, {
  ...
  dom: {
    onBeforeElUpdated(from, to) {
      if (from._x_dataStack) {
        window.Alpine.clone(from, to);
      }
    },
  },
  ...
});

Of course, I could be wrong. But if I'm correct, then this could be a general issue for LiveView  - rather than one for Petal Components. I'll keep an eye on this - once we get to the bottom of it, then I'll update this issue.
For now, I think 3.14.3 might be the go...


Read consensus state

Description
This PR implements the reading and storing of the last consensus events (closes #12).
Clients will be able to subscribe to such changes by subscribing to GraphQL events on the consensus table.
Checklist

[x] Targeted PR against correct branch.
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Wrote unit tests.
[ ] Re-reviewed Files changed in the Github PR explorer.

Codecov Report

Merging #22 into master will increase coverage by 0.62%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##           master      #22      +/-   ##
==========================================
+ Coverage   63.80%   64.43%   +0.62%
==========================================
  Files           6        7       +1
  Lines         420      433      +13
==========================================
+ Hits          268      279      +11
- Misses        114      115       +1
- Partials       38       39       +1

Impacted Files
Coverage Δ

database/consensus.go
84.61% <84.61%> (ø)

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 0f55547...1f33e7b. Read the comment docs.


Allow CFBundleVersionKey to contain only one or two parts.

The CFBundleVersionKey spec allows for one to three period-separated integers. Previously when asked to increment the version this code created a three part version regardless of the originally-supplied value. Now it increments the least-significant part that was supplied.

Many apps (mine included) have used either just one or sometimes two parts in their CFBundleVersionKey, rather than three. This PR allows us to continue doing that. Without it, the PropertyListModifier BundleVersion's incrementPatch function creates an arbitrary patch value even if none was supplied eg
Previously:

incrementing 1 would result in 1.0.1

With the patch:

incrementing 1 will result in 2
incrementing 1.1 will result in 1.2

Incidentally, because the sample specifies a starting value of 1, with this patch it may not be obvious that the code handles three-part version numbers. If you accept the PR perhaps that should be changed to 1.0.0?

@jeff-h thanks for bringing this problem to my attention and authoring this PR. Looking at this problem from first principles, I think BundleVersion now ought to be an enum in order to represent these three possible states. So I did that in #11, could you take a look and let me know if this approach would meet your needs?

Since this issue has been addressed by #11, closing out this PR. Thanks again for highlighting this issue.


[No QA]Remove E2E Detox tests

Details

Removes the End to End detox tests and all documentation, configuration, etc.
Fixed Issues

$ https://github.com/Expensify/Expensify/issues/200011
Tests

[X] Verify that no errors appear in the JS console
[x] Verify that no E2E tests run when submitting a PR (this one included)

PR Review Checklist

Contributor (PR Author) Checklist

[x] I verified the PR has a small number of commits behind main
[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I clearly indicated the environment tests should be run in (Staging vs Production)

[x] I wrote testing steps that cover success & fail scenarios (if applicable)
[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests & veryfy they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors related to changes in this PR
[x] I followed proper code patterns (see Reviewing the code)

[x] I added comments when the code was not self explanatory
[x] I put all copy / text shown in the product in all src/languages/* files (if applicable)
[x] I followed proper naming convention for platform-specific files (if applicable)
[x] I followed style guidelines (in Styling.md) for all style edits I made
[x] I followed the JSDocs style guidelines (in STYLE.md)

[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I corroborated the UI performance was not affected (the performance is the same than main branch)
[x] If I created a new component I verified that a similar component doesn't exist in the codebase

PR Reviewer Checklist

[x] I verified the PR has a small number of commits behind main
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the testing environment is mentioned in the test steps

[x] I verified testing steps cover success & fail scenarios (if applicable)
[x] I checked that screenshots or videos are included for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[x] I verified there are no console errors related to changes in this PR
[x] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified comments were added when the code was not self explanatory
[ ] I verified any copy / text shown in the product was added in all src/languages/* files (if applicable)
[ ] I verified proper naming convention for platform-specific files was followed (if applicable)
[ ] I verified style guidelines were followed
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components are not impacted by changes in this PR (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified the UI performance was not affected (the performance is the same than main branch)
[x] If a new component is created I verified that a similar component doesn't exist in the codebase

QA Steps

No QA steps necessary 👍

Screenshots

Web

N/A
Mobile Web

N/A
Desktop

N/A
iOS

N/A
Android

N/A

🚀 Deployed to staging by @tgolen in version: 1.1.42-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


missing references to build in table sys

while trying to implement tsqlt sql classes I'm getting missing references to the sys schema. e.g. [sys].[extended_properties].
ModelValidationError
error SQL71501: SqlView: [tSQLt].[TestClasses] contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects: [sys].[extended_properties].[ep]::[name], [sys].[extended_properties].[name] or [sys].[schemas].[ep]::[name].

This is probably related to #64. We've asked Microsoft if we are allowed to redistribute the master.dacpac's of various versions of SQL Server, but so far we haven't heard anything yet.

Closing this as a duplicate of #64


How do I use mixin by compass with middleman v4.0.0.rc.1?

middleman version: 4.0.0.rc.1
ruby version: 2.2.3 with rbenv
OS version: OS X 10.10.5
When I added @import "compass"; to site.css.scss, I get an error message displayed Sass::SyntaxError: File to import not found or unreadable: compass. on my web browser.
For example.
$ middleman version
Middleman 4.0.0.rc.1

$ middleman init --skip-bundle
// ...
Do you want to use the Asset Pipeline? y
Do you want to use Compass? y
Do you want to use LiveReload? y
// ...
Do you want a Rack-compatible config.ru file? y

$ bundle install --path vendor/bundle
// ...

$ bundle exec middleman
// success work.

$ vi source/stylesheets/site.css.scss
// 1-1 @charset "utf-8";
//  -2 + @import "compass";
// 2-3 @import "normalize";

$ bundle exec middleman
// I access to localhost:4567 with a web browser, then show 'not found or unreadable: compass'.

$ vi source/stylesheets/site.css.scss
// 1-1 @charset "utf-8";
// 2- - @import "compass";
// 3-2 @import "normalize";
// ..
// 4-4 body {
//  -5 + @include clearfix;
// 5-6 background: #EC561;

$ bundle exec middleman
// I access to localhost:4567 with a web browser, then show "undefined mixin 'clearfix'".

I get $ bundle list
Gems included by the bundle:
  * activesupport (4.2.4)
  * addressable (2.3.8)
  * atomic (1.1.99)
  * backports (3.6.6)
  * bundler (1.10.6)
  * chunky_png (1.3.5)
  * coffee-script (2.4.1)
  * coffee-script-source (<IP_ADDRESS>)
  * compass (1.0.3)
  * compass-core (1.0.3)
  * compass-import-once (1.0.5)
  * contracts (0.9)
  * em-websocket (0.5.1)
  * erubis (2.7.0)
  * eventmachine (1.0.8)
  * execjs (2.6.0)
  * fastimage (1.6.8)
  * ffi (1.9.10)
  * haml (4.0.7)
  * hamster (1.0.0)
  * hashie (3.4.3)
  * http_parser.rb (0.6.0)
  * i18n (0.7.0)
  * json (1.8.3)
  * kramdown (1.9.0)
  * listen (3.0.3)
  * middleman (4.0.0.rc.1)
  * middleman-cli (4.0.0.rc.1)
  * middleman-compass (4.0.0.rc.1)
  * middleman-core (4.0.0.rc.1)
  * middleman-livereload (3.4.3)
  * middleman-sprockets (4.0.0.rc.1)
  * minitest (5.8.2)
  * multi_json (1.11.2)
  * padrino-helpers (0.12.5)
  * padrino-support (0.12.5)
  * rack (1.6.4)
  * rack-livereload (0.3.16)
  * rb-fsevent (0.9.6)
  * rb-inotify (0.9.5)
  * sass (3.4.19)
  * sprockets (3.4.0)
  * thor (0.19.1)
  * thread_safe (0.3.5)
  * tilt (1.4.1)
  * tzinfo (1.2.2)
  * uglifier (2.7.2)

Sprockets and Compass may not be correctly working in conjunction. I'll look into it

I came across almost the same error message when importing breakpoint:
SassC: SyntaxError: Error: File to import not found or unreadable: breakpoint

Gems included by the bundle:
  * activesupport (4.2.4)
  * addressable (2.3.8)
  * ast (2.1.0)
  * astrolabe (1.3.1)
  * atomic (1.1.99)
  * autoprefixer-rails (6.0.3)
  * backports (3.6.6)
  * breakpoint (2.5.0)
  * bundler (1.10.6)
  * capybara (2.5.0)
  * coffee-script (2.4.1)
  * coffee-script-source (<IP_ADDRESS>)
  * compass-import-once (1.0.5)
  * contracts (0.12.0)
  * em-websocket (0.5.1)
  * erubis (2.7.0)
  * eventmachine (1.0.8)
  * execjs (2.6.0)
  * fastimage (1.7.0)
  * ffi (1.9.10)
  * haml (4.0.7)
  * hamster (1.0.0)
  * hashie (3.4.2)
  * htmlcompressor (0.2.0)
  * http_parser.rb (0.6.0)
  * i18n (0.7.0)
  * json (1.8.3)
  * kramdown (1.9.0)
  * listen (3.0.3)
  * middleman (4.0.0.rc.2 3cd84eb)
  * middleman-autoprefixer (2.6.1)
  * middleman-cli (4.0.0.rc.2 3cd84eb)
  * middleman-core (4.0.0.rc.2 3cd84eb)
  * middleman-livereload (3.4.3)
  * middleman-minify-html (3.4.1)
  * mime-types (2.6.2)
  * mini_portile (0.6.2)
  * minitest (5.8.1)
  * nokogiri (<IP_ADDRESS>)
  * padrino-helpers (0.13.0)
  * padrino-support (0.13.0)
  * parser (<IP_ADDRESS>)
  * powerpack (0.1.1)
  * rack (1.6.4)
  * rack-livereload (0.3.16)
  * rack-test (0.6.3)
  * rainbow (2.0.0)
  * rb-fsevent (0.9.6)
  * rb-inotify (0.9.5)
  * rubocop (0.34.2)
  * ruby-progressbar (1.7.5)
  * sass (3.4.19)
  * sassc (1.7.1)
  * sassy-maps (0.4.0)
  * scss_lint (0.42.2)
  * slim (3.0.6)
  * temple (0.7.6)
  * thor (0.19.1)
  * thread_safe (0.3.5)
  * tilt (1.4.1)
  * tzinfo (1.2.2)
  * uglifier (2.7.2)
  * xpath (2.0.0)

For what it's worth, I've been having similar issues since rc.1. If I remember correctly, I've been able to solve all of them by using full file names in my @import statements, ie. @import "mixins.css.sass", where before I used @import "mixins".
For imported gems, I can use @import "breakpoint" without any issue.

I think this was actually a change upstream in Sprockets. I remember renaming some imports for the tests. Valid Sass names should be:
whatever.css.scss for built files.
_whatever.scss for partial/mixins.
I'll see if there's a way to work around Sprockets and enable the original behavior

I've been tried changing the import to include the full extension, but compaas still isn't working.

I this the problem might be here:
https://github.com/middleman/middleman-sprockets/blob/master/lib/middleman-sprockets/extension.rb#L219
?
append_paths_from_gems does not seem to catch the stylesheets folder in compass-core ?

Don't they automatically add their files to sass paths on boot up?

I can confirm middleman-sprockets and middleman-compass aren't playing nice together in middleman rc2

From what I can tell both compass and the modular-scale gem are not adding their paths to the Sass configuration. I'm not familiar enough with compass at the moment to know exactly where and how this problem is happening.

Seems to work fine without sprockets, but with just compass.

@tdreyno yeah, when bothmiddleman-compass and middleman-sprockets are present I get the following error:

As you can see the compass paths are not present. Is the middleman-sprockets gem overriding a configuration instead of appending?
I can confirm this is still an issue in RC3 with the following gems:
site[master] → bundle list | grep middleman
  * middleman (4.0.0.rc.3)
  * middleman-cli (4.0.0.rc.3)
  * middleman-compass (4.0.0.rc.2)
  * middleman-core (4.0.0.rc.3)
  * middleman-sprockets (4.0.0.rc.1)
  * middleman-syntax (2.0.0 e83a478)

The paths are coming from https://github.com/rails/sprockets/blob/3.x/lib/sprockets/sass_processor.rb#L63 I suspect the middleman-compass gem configures the Sass engine first, then the middleman-sprockets gem over writes that config data with these options.

best configuration is
#Middleman
gem 'middleman', '~> 4.0.0.beta.2'

# Middleman-sprockets
gem 'middleman-sprockets', '~> 4.0.0.beta.1'

# Compass
gem 'compass', '1.0.3'

Other wise it's not working.

Calling
::Sass.load_paths.concat(compass.sass_load_paths)

at the end of the ::Compass.configuration block seems to fix this.

@furunkel do you have live example ?

I've added this directly to the Compass extension as well

@tdreyno: Thanks, seems to fix this issue altogether.

:+1: I too can confirm that fixes the issue. Thanks @tdreyno!

:+1:

Released v4.0.1 with this fix.

I was facing a frustrating issue with @import 'breakpoint' not working for me (Google brought me to this issue).
After some experimenting adding the breakpoint gem before the middleman-compass gem fixed my issue. I'm guessing this is some unintended effect of Middleman’s auto-requiring things in the Gemfile. Up until now I've kept the Gemfile organized, and I wasn't expecting behavioral difference due to their order in the Gemfile.

There really shouldn't be any difference between gem order


Connecting to daemon testcontainer postgres

Hello.
I'm using liquibase for DB migrations and would like to use JOOQ with dynamic schema generation and thinking of following use case for testcontainers:

Run liquibase gradle plugin to run migrations against newly created DB instance
Run jooq schema migration to generate Java classes based on just created schema

However I'm having trouble with connecting to started testcontainer. Since I want schema to be preserved I'm using "daemon" property when specifying jdbc url for liquibase: jdbc:tc:postgresql:9.6.8://hostname/databasename?TC_DAEMON=true
However I'm not able to connect to created DB from next step - when running jooq. If I set same url it would just start a new container. And regular jdbc url like jdbc:postgres://localhost:5432/service fails (likely because postgres container is running on a different port, not 5432. And I can dynamically set correct port because it's not code, but gradle thing).
Gradle configuration is following:
// Liquibase plugin to run migration script
liquibase {
  activities {
    main {
      changeLogFile 'src/main/resources/ddl/master-changelog.yaml'
      url 'jdbc:tc:postgresql:9.6.8://hostname/databasename?TC_DAEMON=true'
      driver 'org.testcontainers.jdbc.ContainerDatabaseDriver'
      username 'postgres'
      password ''
    }
  }
  runList = 'main'
}

jooq {
  version = '3.10.4'
  edition = 'OSS'
  service(sourceSets.main) {
    jdbc {
      driver = 'org.testcontainers.jdbc.ContainerDatabaseDriver'
      url = 'jdbc:postgres://localhost:5432/service'
      user = 'postgres'
      password = ''
    }
    generator {
      name = 'org.jooq.util.DefaultGenerator'
      strategy {
        name = 'org.jooq.util.DefaultGeneratorStrategy'
      }
      database {
        name = 'org.jooq.util.postgres.PostgresDatabase'
        inputSchema = 'service'
      }
      generate {
        relations = true
        records = true
        pojos = true
        fluentSetters = true
      }
      target {
        packageName = 'com.example.service.persistence.jooq'
        directory = './build/generated/source/jooq/main'
      }
    }
  }
}

generateServiceJooqSchemaSource.dependsOn dbUpdate

Could you please advice if it is possible to connect to daemon using only gradle configuration?
Thanks.

In your JOOQ config, you should be using the same JDBC string:
'jdbc:tc:postgresql:9.6.8://hostname/databasename?TC_DAEMON=true'

Actually, I tried something similar with Flyway and jOOQ, and hit a fatal problem.
IIRC the Gradle jOOQ plugin runs in a forked JVM to avoid classpath conflicts, and unfortunately this means that you end up with two instances of Testcontainers, each with its own connection:container cache. Right now we have no way to share containers between JVMs.
I'm afraid I've not yet found a way to do this with Testcontainers.

Thank you @rnorth, that answers the question


add tags

could you please consider adding tags for each version so that we can add your lib on https://cdnjs.com with git auto-update.
thank you very much!
https://github.com/cdnjs/cdnjs/issues/5683

Yes.  Please tag a release.

Is there a way we can get another tag added and then maybe the bower.json to updated? Thanks! The biggest change is the http to https and when you just do bower install now you get the version without the https. Thanks!


feat: allow to specify a previous configuration

References CAR-8766
Currently we have a hard limit when the bundlesize check fails (e.g. 225kb in listings). This is applicable for around 5 pages. All other pages are a lot smaller and as a result, we cannot notice if we impact the size of those pages without a lot of effort
Newly, this package will accepts a config file that is used additionally to the hard limit. It also creates a new updated version of the configuration that can be used for further modifications.
Here is the PR in listings: https://github.com/carforyou/carforyou-listings-web/pull/3852


Add text clarifying that only RNA-seq samples are currently in MetaSRA

Either with a ? icon to the right of "Find human RNA-seq samples" and/or text on the About tab, it would be good to clarify that the current MetaSRA only contains RNA-seq samples, but that future releases will include samples from other assays.  Possible text would be:
"The MetaSRA currently annotates each human RNA-seq sample in the Sequence Read Archive (SRA) using standardized terms from biomedical ontologies.  Future releases of the MetaSRA will include samples from other species and assays."

Added a ? icon and popup with your text, and added FAQ questions.


In Next js 13.5 react-vertical-timeline not working

In Next js 13.5 react-vertical-timeline not working. content not visible

Have the same issue. It's an issue with animation.
If VerticalTimeline's animation to false or VerticalTimelineElement's visible to true, it appears on screen.

Same here! As @D-Kunrath has suggested, this can be fixed by adding a visible="true" attribute to VerticalTimelineElement. In my case. using React.js/Next.js this is what the fixed code looked like:
<VerticalTimeline lineColor=''>                 {experiencesData.map((item, index) => (                     <React.Fragment key={index}>                         <VerticalTimelineElement                             **visible={true}**                                                               contentStyle={{

If we set VerticalTimeline's animation to false or VerticalTimelineElement's visible to true, it appears on screen.
That does make the content visible but stops the default animation of popping up VerticalTimelineElement as the component appears in the viewport.

For "next": "13.4.8", it is working.

The animation does not work for me either in next 13.5.2. I added animate={true} to VerticalTimelin, but this had no effect:
<VerticalTimeline lineColor='' animate={true}>

For "next": "13.4.8", it is working.
Hi @souravdasdip , yes for 13.4 it works but it does not work for 13.5. That's the issue.

The animation does not work for me either in next 13.5.2. I added animate={true} to VerticalTimelin, but this had no effect: <VerticalTimeline lineColor='' animate={true}>

For "next": "13.4.8", it is working.
Hi @souravdasdip , yes for 13.4 it works but it does not work for 13.5. That's the issue.

Yes the animation is not working @ananta-dev next 13.5.2

With next 13.5.2 is not working on local but when it's deploy I have no issue.

Use inView() from react-intersection-observer
const {ref, inView} = inView()

Use inView() from react-intersection-observer const {ref, inView} = inView() In element visible={inView}and use ref to first child of element

Does this make the animation work?

Hi @farrukh007,
That's exactly my code.
Did you get the animation to work? If so, how?

Hi @farrukh007
After reading @D-Kunrath's comment I looked at the documentation, here: https://stephane-monnot.github.io/react-vertical-timeline/#/
If you scroll down and you will see:
visible={ Boolean } #

Hi @farrukh007 After reading @D-Kunrath's comment I looked at the documentation, here: https://stephane-monnot.github.io/react-vertical-timeline/#/
If you scroll down you will see: visible={ Boolean } #

hi dear will you assist me one thing more about how may I resize the vertical timeline element?

Hi @farrukh007 !
This is not a discord channel. It is very specific gihub issue.
I would recommend you follow the documentation link I shared in my previous post and you look for style={ Object } - Add extra style to root div element. You can use that to change the appearance of the timeline element.

Actually, you can set it like this for react-vertical-timeline-component in Next.js 13.5,
import { useInView } from "react-intersection-observer";
const { ref, inView } = useInView({
triggerOnce: true,
});

        {experiences.map((experience, index) => (

{experience.title}
{experience.location}

              {experience.description}

        ))}

;
in this case, I only trigger the inView callback animation once. Hopefully it helps✌🏼

Actually, you can set it like this for react-vertical-timeline-component in Next.js 13.5,
`import { useInView } from "react-intersection-observer";
const { ref, inView } = useInView({
triggerOnce: true,
});

My Experience

        {experiences.map((experience, index) => (
          in this case, I only trigger the inView callback animation once. Hopefully it helps✌🏼

Actually, you can set it like this for react-vertical-timeline-component in Next.js 13.5,
import { useInView } from "react-intersection-observer";

const { ref, inView } = useInView({
    triggerOnce: true,
  });

  <VerticalTimeline lineColor="#e4e4e7">
        {experiences.map((experience, index) => (
          <VerticalTimelineElement
            visible={inView}
            date={experience.date}
            icon={experience.icon}
            key={index}...

in this case, I only trigger the inView callback animation once. Hopefully it helps✌🏼

Thank you @diosetiad. That makes the animation work. That's great.
However, with your solution the whole VerticalTimeLine is treated as a single block for the triggering of the animation. The whole timeline is animated at once. There are no individual animations for each VerticalTimeElement as we would expect.
I have tried to generate individual refs for each element, even using the component  instead of the hook (useInView) but did not succeed so far.
Do you have any idea how we may animate each VerticalTimelineElement individually, while maintaining the dynamic experiences.map structure?

Here is the full solution. Ignore line 14. Need to use vissible={true} or use the useInViewfrom 'react-intersection-observer' to keep the animations.
`'use client';
import React from 'react';
import { useSectionInView } from '@/lib/hooks';
import SectionHeading from './section-heading';
import {
VerticalTimeline,
VerticalTimelineElement,
} from 'react-vertical-timeline-component';
import 'react-vertical-timeline-component/style.min.css';
import { experiencesData } from '@/lib/data';
import { useInView } from 'react-intersection-observer';
export default function Experience() {
const { ref } = useSectionInView('Experience');
return (

My Experience

{experiencesData.map((item, index) => {
const { ref, inView } = useInView({
triggerOnce: true,
});
return (

<VerticalTimelineElement
contentStyle={{
background: '#f3f4f6',
boxShadow: 'none',
border: '1px solid rgba(0, 0, 0, 0.05)',
textAlign: 'left',
padding: '1.3rem 2rem',
}}
contentArrowStyle={{
borderRight: '0.4rem solid #9ca3af',
}}
visible={inView}
date={item.date}
icon={item.icon}
iconStyle={{
background: 'white',
fontSize: '1.5rem',
}}
>
{item.title}
{item.location}

{item.description}

);
})}

);
}
`

Great job @SebastienRamsay! It works beautifully.
Would have never thought of moving the hook call inside the map callback. I have learned something from you. Thank you.
For those who would prefer the animation to replay if the user scrolls back up and then down again, one can change this:
 <VerticalTimeline lineColor="">
        {experiencesData.map((item, index) => {
          const { ref, inView } = useInView({
            triggerOnce: true,
          });
          return (

to this:
 <VerticalTimeline lineColor="">
        {experiencesData.map((item, index) => {
          const { ref, inView } = useInView({ threshold: 0 });
          return (

Question @SebastienRamsay
The solution worked locally, but when I deployed to Vercel, I got this error:
...
[06:30:04.703]    Linting and checking validity of types...
[06:30:07.064]
[06:30:07.064] Failed to compile.
[06:30:07.064]
[06:30:07.064] ./components/experience.tsx
[06:30:07.065] 26:45  Error: React Hook "useInView" cannot be called inside a callback. React Hooks must be called in a React function component or a custom React Hook function.  react-hooks/rules-of-hooks
[06:30:07.065]
[06:30:07.065] info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
[06:30:07.168] Error: Command "npm run build" exited with 1

It appears eslint does not like me calling a hook from inside a callback.
Did you have this issue when deploying?
What's your best way to solve it?

Update:
I managed to get rid of the Vercel deployment eslint error by breaking the extracting the callback to a separate component, like this:
'use client'
import React from 'react'
import { useSectionInView } from '@/lib/hooks'
import SectionHeading from './sectionHeading'
import {
    VerticalTimeline,
    VerticalTimelineElement,
} from 'react-vertical-timeline-component'
import 'react-vertical-timeline-component/style.min.css'
import { experiencesData } from '@/lib/data'
import { useInView } from 'react-intersection-observer'
import { useTheme } from '@/context/themeContext'

type ExperienceElementProps = {
    theme: string
    item: {
        date: string
        icon: React.ReactNode
        title: string
        location: string
        description: string
    }
}

const ExperienceElement = ({ theme, item }: ExperienceElementProps) => {
    const { ref, inView } = useInView({ threshold: 0 })
    return (

            <VerticalTimelineElement
                visible={inView}
                contentStyle={{
                    background:
                        theme === 'light'
                            ? '#f3f4f6'
                            : 'rgba(255, 255, 255, 0.05)',
                    boxShadow: 'none',
                    border: '1px solid rgba(0, 0, 0, 0.05)',
                    textAlign: 'left',
                    padding: '1.3rem 2rem',
                }}
                contentArrowStyle={{
                    borderRight:
                        theme === 'light'
                            ? '0.4rem solid #9ca3af'
                            : '0.4rem solid rgba(255, 255, 255, 0.5)',
                }}
                date={item.date}
                icon={item.icon}
                iconStyle={{
                    background:
                        theme === 'light' ? 'white' : 'rgba(29, 36, 50, 0.95)',
                    fontSize: '1.5rem',
                }}
            >

{item.title}

{item.location}

                    {item.description}

            </VerticalTimelineElement>

    )
}

export default function Experience() {
    const { ref } = useSectionInView('Experience')
    const { theme } = useTheme()
    return (

            <SectionHeading>My Experience</SectionHeading>
            <VerticalTimeline lineColor=''>
                {experiencesData.map((item, index) => (
                    <ExperienceElement key={index} theme={theme} item={item} />
                ))}
            </VerticalTimeline>

    )
}

Credit to this Stackoverflow answer:
https://stackoverflow.com/questions/55963914/react-usecallback-hook-for-map-rendering/55963994#55963994
Unfortunately (for me) the deployed version does not replay animation when the user scrolls back up to above the timeline and then down again to bring the timeline into view for a second time. Has anyone managed to get it to work after deploying?

@ananta-dev sorry for replying now, we can animate each VerticalTimelineElement individually like this :
create a TimelineElement component to avoid eslint errors.
import { VerticalTimelineElement } from "react-vertical-timeline-component";
import "react-vertical-timeline-component/style.min.css";
import { useInView } from "react-intersection-observer";

export default function TimelineElement({ item }) {
  const { ref, inView } = useInView({
    triggerOnce: true,
  });

  return (

      <VerticalTimelineElement
        contentStyle={{
          ...
        }}
        contentArrowStyle={{
          ...
        }}
        date={item.date}
        icon={item.icon}
        iconStyle={{
          ...
        }}
        visible={inView}
      >

{item.title}

{item.location}

          {item.description}

      </VerticalTimelineElement>

  );
}

import TimelineElement to main component.
("use client");
import { experiencesData } from "@/lib/data";
import { VerticalTimeline } from "react-vertical-timeline-component";
import TimelineElement from "./timeline-element";
export default function Experience() {
  return (

      <VerticalTimeline lineColor="#e4e4e7">
        {experiencesData.map((item, index) => {
          return <TimelineElement key={index} item={item} />;
        })}
      </VerticalTimeline>

  );
}

now the animation definitely works and there are no eslint errors. Hopefully it helps✌🏼

🤦

@ananta-dev sorry for replying now, we can animate each VerticalTimelineElement individually like this :
create a TimelineElement component to avoid eslint errors.
import { VerticalTimelineElement } from "react-vertical-timeline-component";
import "react-vertical-timeline-component/style.min.css";
import { useInView } from "react-intersection-observer";

export default function TimelineElement({ item }) {
  const { ref, inView } = useInView({
    triggerOnce: true,
  });

  return (

      <VerticalTimelineElement
        contentStyle={{
          ...
        }}
        contentArrowStyle={{
          ...
        }}
        date={item.date}
        icon={item.icon}
        iconStyle={{
          ...
        }}
        visible={inView}
      >

{item.title}

{item.location}

          {item.description}

      </VerticalTimelineElement>

  );
}

import TimelineElement to main component.
"use client";
import { experiencesData } from "@/lib/data";
import { VerticalTimeline } from "react-vertical-timeline-component";
import TimelineElement from "./timeline-element";
export default function Experience() {
  return (

      <VerticalTimeline lineColor="#e4e4e7">
        {experiencesData.map((item, index) => {
          return ( <TimelineElement key={index} item={item} /> );
        })}
      </VerticalTimeline>

  );
}

now the animation definitely works and there are no eslint errors. Hopefully it helps✌🏼

Update:
I managed to get rid of the Vercel deployment eslint error by extracting the callback to a separate component, like this:
'use client'
import React from 'react'
import { useSectionInView } from '@/lib/hooks'
import SectionHeading from './sectionHeading'
import {
    VerticalTimeline,
    VerticalTimelineElement,
} from 'react-vertical-timeline-component'
import 'react-vertical-timeline-component/style.min.css'
import { experiencesData } from '@/lib/data'
import { useInView } from 'react-intersection-observer'
import { useTheme } from '@/context/themeContext'

type ExperienceElementProps = {
    theme: string
    item: {
        date: string
        icon: React.ReactNode
        title: string
        location: string
        description: string
    }
}

const ExperienceElement = ({ theme, item }: ExperienceElementProps) => {
    const { ref, inView } = useInView({ threshold: 0 })
    return (

            <VerticalTimelineElement
                visible={inView}
                contentStyle={{
                    background:
                        theme === 'light'
                            ? '#f3f4f6'
                            : 'rgba(255, 255, 255, 0.05)',
                    boxShadow: 'none',
                    border: '1px solid rgba(0, 0, 0, 0.05)',
                    textAlign: 'left',
                    padding: '1.3rem 2rem',
                }}
                contentArrowStyle={{
                    borderRight:
                        theme === 'light'
                            ? '0.4rem solid #9ca3af'
                            : '0.4rem solid rgba(255, 255, 255, 0.5)',
                }}
                date={item.date}
                icon={item.icon}
                iconStyle={{
                    background:
                        theme === 'light' ? 'white' : 'rgba(29, 36, 50, 0.95)',
                    fontSize: '1.5rem',
                }}
            >

{item.title}

{item.location}

                    {item.description}

            </VerticalTimelineElement>

    )
}

export default function Experience() {
    const { ref } = useSectionInView('Experience')
    const { theme } = useTheme()
    return (

            <SectionHeading>My Experience</SectionHeading>
            <VerticalTimeline lineColor=''>
                {experiencesData.map((item, index) => (
                    <ExperienceElement key={index} theme={theme} item={item} />
                ))}
            </VerticalTimeline>

    )
}

Credit to this Stackoverflow answer: https://stackoverflow.com/questions/55963914/react-usecallback-hook-for-map-rendering/55963994#55963994
Unfortunately (for me) the deployed version does not replay animation when the user scrolls back up to above the timeline and then down again to bring the timeline into view for a second time. Has anyone managed to get it to work after deploying?

Yeah this stumped me, using hooks has to be at the top level of the component, so extracting it into a separate component worked like a charm like the solution you found! Glad we're all sharing this with each other, helps to see other perspectives for problem solving!

Use inView() from react-intersection-observer const {ref, inView} = inView() In element visible={inView}and use ref to first child of element

Does this make the animation work?

I've noticed that the animation in my project seems to be extremely fast, making it difficult to notice the animation itself. The first time I run the animation, it appears as though it's not working as intended.
I've tried the following solution, which has worked for me, but it still not perfect:
const { ref, inView } = useInView({
threshold: 0.25
})
return (

My experience

{experiencesData.map((item, index) => (
<React.Fragment key={index}>
<VerticalTimelineElement
visible={inView}
contentStyle={{

I am facing the same issue in Next.js 14.0.3.

"use client";
import React from "react";
import SectionHeading from "./section-heading";
import {
VerticalTimeline,
VerticalTimelineElement,
} from "react-vertical-timeline-component";
import "react-vertical-timeline-component/style.min.css";
import { experiencesData } from "@/lib/data";
import { useSectionInView } from "@/lib/hooks";
import { useTheme } from "@/context/theme-context";
export default function Experience() {
const { ref } = useSectionInView("Experience");
const { theme } = useTheme();
return (

My experience

{experiencesData.map((item, index) => {
return (
<React.Fragment key={index}>
<VerticalTimelineElement
contentStyle={{
background:
theme === "light" ? "#f3f4f6" : "rgba(255, 255, 255, 0.05)",
boxShadow: "none",
border: "1px solid rgba(0, 0, 0, 0.05)",
textAlign: "left",
padding: "1.3rem 2rem",
}}
contentArrowStyle={{
borderRight:
theme === "light"
? "0.4rem solid #9ca3af"
: "0.4rem solid rgba(255, 255, 255, 0.5)",
}}
date={item.date}
icon={item.icon}
iconStyle={{
background:
theme === "light" ? "white" : "rgba(255, 255, 255, 0.15)",
fontSize: "1.5rem",
}}
>
{item.title}
{item.location}

{item.description}

</React.Fragment>
);
})}

);
}

The content inside VerticalTimelineElement is not reflecting

guys timeline library doesnt support SSR in Nextjs . You can no try use it more in next

https://ricardo-portfolio-site.vercel.app/
Check this out it's working

With next 13.5.2 is not working on local but when it's deploy I have no issue.

same for me.

I have next 13.5 but i get this problem:
node_modules\react-intersection-observer\react-intersection-observer.js
Caused by:
The system cannot find the file specified. (os error 2)

you could just return the inView in your custom Hook
return {     ref,     inView,   }
modify the  const { ref} = useSectionInView('Experience')
to
 const { ref, inView } = useSectionInView('Experience')
and set your visible to inView

you could just return the inView in your custom Hook return { ref, inView, } modify the  const { ref} = useSectionInView('Experience') to  const { ref, inView } = useSectionInView('Experience') and set your visible to inView

yes you are right, but this make animate the component as a whole since you have one and same inView for the all timeline elements. In order to animate timeline elements one by one, you need to follow @diosetiad recommendation

you could just return the inView in your custom Hook return { ref, inView, } modify the  const { ref} = useSectionInView('Experience') to  const { ref, inView } = useSectionInView('Experience') and set your visible to inView

yes you are right, but this animate the component as a whole since you have one and same inView prop for the all timeline elements. In order to animate timeline elements one by one, you need to follow @diosetiad recommendation. Its up to you how you'd like to animate

For that I did
const [isInView, setIsInView] = useState(false)   useEffect(() => {     if (inView) {       setIsInView(true)     }   }, [inView])
And set visible=isInView because I faced the same problem.

It worked for me even with next 14:

// package.json
{
  "name": "portfolio",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "@react-email/components": "^0.0.7",
    "@react-email/tailwind": "^0.0.8",
    "@types/node": "20.3.2",
    "@types/react": "18.2.14",
    "@types/react-dom": "18.2.6",
    "autoprefixer": "10.4.14",
    "clsx": "^1.2.1",
    "eslint": "8.43.0",
    "eslint-config-next": "13.4.7",
    "framer-motion": "^10.12.17",
    "next": "14.1.0",
    "postcss": "8.4.24",
    "react": "^18",
    "react-dom": "^18",
    "react-hot-toast": "^2.4.1",
    "react-icons": "^4.10.1",
    "react-intersection-observer": "^9.5.2",
    "react-vertical-timeline-component": "^3.6.0",
    "resend": "^0.16.0",
    "tailwindcss": "3.3.2",
    "typescript": "5.1.5"
  },
  "devDependencies": {
    "@types/react-vertical-timeline-component": "^3.3.3"
  }
}

"use client";

import React from "react";
import SectionHeading from "./section-heading";
import {
  VerticalTimeline,
  VerticalTimelineElement,
} from "react-vertical-timeline-component";
import "react-vertical-timeline-component/style.min.css";
import { experiencesData } from "@/lib/data";
import { useTheme } from "@/context/theme-context";
import { useInView } from "react-intersection-observer";

export default function Experience() {
  const { theme } = useTheme();
  const { ref, inView } = useInView({
    triggerOnce: true,
  });

  return (

      <SectionHeading>My experience</SectionHeading>
      <VerticalTimeline lineColor="">
        {experiencesData.map((item, index) => (
          <React.Fragment key={index}>
            <VerticalTimelineElement
              visible={inView}
              contentStyle={{
                background:
                  theme === "light" ? "#f3f4f6" : "rgba(255, 255, 255, 0.05)",
                boxShadow: "none",
                border: "1px solid rgba(0, 0, 0, 0.05)",
                textAlign: "left",
                padding: "1.3rem 2rem",
              }}
              contentArrowStyle={{
                borderRight:
                  theme === "light"
                    ? "0.4rem solid #9ca3af"
                    : "0.4rem solid rgba(255, 255, 255, 0.5)",
              }}
              date={item.date}
              icon={item.icon}
              iconStyle={{
                background:
                  theme === "light" ? "white" : "rgba(255, 255, 255, 0.15)",
                fontSize: "1.5rem",
              }}
            >

{item.title}

{item.location}

                {item.description}

            </VerticalTimelineElement>
          </React.Fragment>
        ))}
      </VerticalTimeline>

  );
}

It worked for me even with next 14:
// package.json
{
  "name": "portfolio",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "@react-email/components": "^0.0.7",
    "@react-email/tailwind": "^0.0.8",
    "@types/node": "20.3.2",
    "@types/react": "18.2.14",
    "@types/react-dom": "18.2.6",
    "autoprefixer": "10.4.14",
    "clsx": "^1.2.1",
    "eslint": "8.43.0",
    "eslint-config-next": "13.4.7",
    "framer-motion": "^10.12.17",
    "next": "14.1.0",
    "postcss": "8.4.24",
    "react": "^18",
    "react-dom": "^18",
    "react-hot-toast": "^2.4.1",
    "react-icons": "^4.10.1",
    "react-intersection-observer": "^9.5.2",
    "react-vertical-timeline-component": "^3.6.0",
    "resend": "^0.16.0",
    "tailwindcss": "3.3.2",
    "typescript": "5.1.5"
  },
  "devDependencies": {
    "@types/react-vertical-timeline-component": "^3.3.3"
  }
}

// vertical timeline component

"use client";

import React from "react";
import SectionHeading from "./section-heading";
import {
  VerticalTimeline,
  VerticalTimelineElement,
} from "react-vertical-timeline-component";
import "react-vertical-timeline-component/style.min.css";
import { experiencesData } from "@/lib/data";
import { useTheme } from "@/context/theme-context";
import { useInView } from "react-intersection-observer";

export default function Experience() {
  const { theme } = useTheme();
  const { ref, inView } = useInView({
    triggerOnce: true,
  });

  return (

      <SectionHeading>My experience</SectionHeading>
      <VerticalTimeline lineColor="">
        {experiencesData.map((item, index) => (
          <React.Fragment key={index}>
            <VerticalTimelineElement
              visible={inView}
              contentStyle={{
                background:
                  theme === "light" ? "#f3f4f6" : "rgba(255, 255, 255, 0.05)",
                boxShadow: "none",
                border: "1px solid rgba(0, 0, 0, 0.05)",
                textAlign: "left",
                padding: "1.3rem 2rem",
              }}
              contentArrowStyle={{
                borderRight:
                  theme === "light"
                    ? "0.4rem solid #9ca3af"
                    : "0.4rem solid rgba(255, 255, 255, 0.5)",
              }}
              date={item.date}
              icon={item.icon}
              iconStyle={{
                background:
                  theme === "light" ? "white" : "rgba(255, 255, 255, 0.15)",
                fontSize: "1.5rem",
              }}
            >

{item.title}

{item.location}

                {item.description}

            </VerticalTimelineElement>
          </React.Fragment>
        ))}
      </VerticalTimeline>

  );
}

You are not using  useSectionInView, if you did, it would not work to setActiveSection as you scroll, your setion ref does nothing on your code

visible={inView}

Thanks @SebastienRamsay  , this works well , and its is easy to impliment with next ! good job


Upgrade rubocop to 0.29

Provides additional cops and options for existing cops
Fix easy formatting errors
Disable (new) struct inheritance cop for now

@Gerg ,
Looks great! Thanks!
@wendorf, Cloud Foundry CAPI team


delete proxy trap not implemented

Observations occur when:
object.foo = undefined;

But not when:
delete object[foo];

occurs. Probably just need to add some ObservationRecorder.adds?

Probably just needs to dispatch an event similar to set.

Actually this can't easily be implemented. define() sets up property descriptors, and therefore delete foo.bar will not hit the proxy trap. You'd have to add another proxy on the instance itself, I think.


Documentation claims "allow_drag_and_drop" default is false, but it's true

Thanks for this amazing library! Really helps us a lot :)
In the latest .min version of the library, the documentation claims that the default of allow_drag_and_drop is false, but seems to actually be true. At least without setting it to false in the setup, it's possible to drag and drop STL files.
Minor bug of course :)

Thanks Albert - you are right!!! 👍
But, the bug is not in the plugin, but in the docs😄

will be fixed ASAP


pmi has duplicate jobs on our search engine

peviitor.ro write 9 jobs, but they are duplicate.

GATA!