Recherche avancée

Sur d’autres sites (11645)

• Revision 73edeb03ea : Removing alg_priv from vpx_codec_priv struct. In order to understand memory lay

  21 août 2014, par Dmitry Kovalev

  Changed Paths :
   Modify /vp8/vp8_cx_iface.c

  
   Modify /vp8/vp8_dx_iface.c

  
   Modify /vp9/vp9_cx_iface.c

  
   Modify /vp9/vp9_dx_iface.c

  
   Modify /vpx/internal/vpx_codec_internal.h

  
   Modify /vpx/src/vpx_codec.c

  
   Modify /vpx/src/vpx_decoder.c

  
   Modify /vpx/src/vpx_encoder.c

  
  
  Removing alg_priv from vpx_codec_priv struct.

  In order to understand memory layout consider the declaration of the
  following structs. The first one is a part of our API :

  struct vpx_codec_ctx
  // ...
  struct vpx_codec_priv *priv ;
   ;

  The second one is defined in vpx_codec_internal.h :

  struct vpx_codec_priv
  // ...
   ;

  The following struct is defined 4 times for encoder/decoder VP8/VP9 :

  struct vpx_codec_alg_priv
  struct vpx_codec_priv base ;
  // ...
   ;

  Private data allocation for the given ctx :

  struct vpx_codec_ctx *ctx =
  struct vpx_codec_alg_priv *alg_priv =
  ctx->priv = (struct vpx_codec_priv *)alg_priv ;

  The cast works because vpx_codec_alg_priv has a
  vpx_codec_priv instance as a first member ’base’.

  Change-Id : I10d1afc8c9a7dfda50baade8c7b0296678bdb0d0

• Anomalie #4354 : Problème de recherche REGEX, mauvais joker

  19 juin 2019, par Jimmy Laporte

  b b a écrit :

  Salut, je ne reproduis pas chez moi avec SPIP 3.3, la recherche fonctionne sans problème avec ce titre.

  Ça ressemble à un problème du côté base de données, chez moi la table spip_articles est bien en utf8_general_ci, est-ce bien le cas de ton côté ?

  On dirait bien un doublon de #3930.

  Alors, là j’ai le bug sur 3.2.4, php 7.2.12, mysql 5.0.12-dev et c’est bien de l’utf8_general_ci

  Si tu veux tester le problème, j’ai installé un spip vierge tout frais pour illustrer :

  http://spip.telkea.com/ecrire
  login : demo
  pwd : testtest

  et tu recherches "Fêtes et Cérémonies", tu verras que l’article ne sort pas => http://spip.telkea.com/ecrire/?exec=recherche&recherche=F%C3%AAtes%20et%20C%C3%A9r%C3%A9monies
  tandis que si je modifie le joker "." en ".*" ça marche => http://spip.telkea.com/ecrire/?exec=recherche&recherche=F%C3%AAtes%20et%20C%C3%A9r%C3%A9monies&fix=true

   ;)

• Anomalie #3535 : liste des rédacteurs connectés

  16 août 2017, par Julien -

  Sur un SPIP 3.2b, (migré depuis un 2.1 > 3.1 > 3.2b), j’ai en effet 4 types de valeur pour imessage : "oui", "non", vide, NULL.
  (Et une condition SQL imessage != 'non' retourne le vide mais pas le NULL).

  Au niveau MySQL, la colonne imessage n’a pas de NOT NULL.
  Au niveau du code SPIP, on trouve :
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/maj/v012.php#L35 : création initial en NOT NULL

  Il semble que sur une installation neuve :
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L225 : le "field" est absent (bien que référencé dans "champs_editables" L223)

  C’est l’organiseur qui semble gérer la création de imessage et messagerie :
  https://core.spip.net/projects/organiseur/repository/entry/base/organiseur.php#L27
  => Il crée ces champs sans préciser de NOT NULL contrairement à v012.php

  A noter que sur une base en SPIP 2.1, je vois que j’ai tout de même "OUI" à la propriété NOT NULL !!

  Au niveau du code SPIP, il semble que les conditions portent toujours sur != 'non'.
  Ne faudrait-il pas plutôt corriger la définition de la colonne en mettant un NOT NULL DEFAULT '' ?