Recherche avancée

Sur d’autres sites (6865)

• Anomalie #3504 : anomalie dans cvt_autosave : les purges ne se font pas

  23 juillet 2015, par Peet du

  Tu as raison...une fois que tu valides ton formulaire (avec _autosave activé), les données de session concernant CE formulaire sont bien purgées. Pas de bug en l’état puisque ce traitement n’est pas basé sur la constante _AUTOSAVE_GB_DELAY

  Ce que j’avais oublié de préciser dans mon post, c’est que le bug signalé se situe dans la deuxième partie du traitement, celle qui "purge aussi toutes les vieilles autosave". C’est elle qui est basée sur _AUTOSAVE_GB_DELAY.
  Voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/cvt_autosave.php#L88

  Si j’ai bien compris, elle traite le cas où le site contient plusieurs formulaires CVT avec l’autosave activé. Dans ce cas on purge également ces sessions.
  Et c’est là que le bug sur le timestamp fait son office. Ces vieilles sessions ne seront jamais purgés.

  SUGGESTION
  Perso, je trouve que ce fonctionnement est astucieux, mais il induit un fonctionnement confus pour l’utilisateur et pour le développeur.
  Si le visiteur revient sur son formulaire, (même 1 an après) il trouve les champs remplis puisque _AUTOSAVE_GB_DELAY n’est pas pris en compte dans ce cas . Il valide son formulaire et sa session pour ce formulaire est purgé.
  Puis dans la foulée il arrive sur un autre formulaire et là....rien ?! (ben oui, il a validé le premier et la purge basée sur _AUTOSAVE_GB_DELAY a fonctionnée (si on corrige le bug hein ;-)

  Bref, perso j’ai modifié le core (je sais, c’est mal) en mettant les purges uniquement basée sur _AUTOSAVE_GB_DELAY dans la fonction cvtautosave_formulaire_charger. On (peut) garder la purge à la validation du formulaire.

  SUGGESTION 2
  L’idéal serait, selon moi, de garder cette dernière idée avec un ajout : on purge dans le répertoire /sessions toutes les données de tous les utilisateurs pour lesquels la valeurs _AUTOSAVE_GB_DELAY a été dépassé. Ça marche bien et de plus, d’un point de vue de sécurité, cela règle en partie le problème des personnes qui on mal lu la doc sur la partie "Vie privée" (voir http://www.spip.net/fr_article5428.html).

  SUGGESTION 3
  même si vous n’êtes pas d’accord avec mon analyse, serait-il possible de mettre

  • cvtautosave_formulaire_charger
  • cvtautosave_formulaire_traiter

  en _dist ?

• Working directory in Dockerfile is not what is expected to be

  31 mai 2022, par user1765862

  I have following Dockerfile

  


  FROM public.ecr.aws/lambda/dotnet:6 AS base

FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim as build
WORKDIR /src
COPY ["AWSServerless.csproj", "AWSServerless/"]
RUN dotnet restore "AWSServerless/AWSServerless.csproj"

WORKDIR "/src/AWSServerless"
COPY . .
RUN dotnet build "AWSServerless.csproj" --configuration Release --output /app/build

FROM build AS publish

RUN apt-get update && apt-get install -y apt-utils libgdiplus libc6-dev

RUN apt-get install -y ffmpeg

RUN dotnet publish "AWSServerless.csproj" \
            --configuration Release \ 
            --runtime linux-x64 \
            --self-contained false \ 
            --output /app/publish \
            -p:PublishReadyToRun=true  

FROM base AS final
WORKDIR /var/task

CMD ["AWSServerless::AWSServerless.LambdaEntryPoint::FunctionHandlerAsync"]
COPY --from=publish /app/publish .


  


  As per ffmpeg docs In order to use ffmpeg I need to set its binary folder
for example with

  


  {
  "BinaryFolder": "/var/task",
  "TemporaryFilesFolder": "/tmp"
}


  


  Error

  


  


  An error occurred trying to start process './ffmpeg' with working
directory '/var/task'. No such file or directory

  


  


  What is the working directory here ?

  


  Update :
Actual error is being thrown when I try to execute following command (FFMpegCore package) from my api controller

  


  public class MyController : ControllerBase&#xA;{&#xA;    public async Task<string> Get()&#xA;    {    &#xA;         await FFMpegArguments&#xA;               .FromPipeInput(new StreamPipeSource(myfile))&#xA;               .OutputToPipe(new StreamPipeSink(outputStream), options => options&#xA;                  .WithVideoCodec("vp9")&#xA;                  .ForceFormat("webm"))&#xA;                  .ProcessAsynchronously();&#xA;         ...&#xA;    }    &#xA;}&#xA;</string>

  


• avutil/libm : correct isnan, isinf compat hacks

  15 novembre 2015, par Ganesh Ajjanagadde

  avutil/libm : correct isnan, isinf compat hacks
  isnan and isinf are actually macros as per the standard. In particular,
  
  the existing implementation has incorrect signature. Furthermore, this
  
  results in undefined behavior for e.g double values outside float range
  
  as per the standard.
  This patch corrects the undefined behavior for all usage within FFmpeg.
  Note that long double is not handled as it is not used in FFmpeg.
  
  Furthermore, even if at some point long double gets used, it is likely
  
  not needed to modify the macro in practice for usage in FFmpeg. See
  
  below for analysis.
  Getting long double to work strictly per the spec is significantly harder
  
  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
  
  extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
  
  On the other hand, any potential future usage of long double is likely
  
  for precision (when a platform offers extra precision) and not for range, since
  
  the range anyway varies and is not as portable as IEEE 754 single/double
  
  precision. In such cases, the implicit cast to a double is well defined
  
  and isinf and isnan should work as intended.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/libm.h