Recherche avancée

Sur d’autres sites (10860)

• what is 'linesize alignment' meaning ?

  27 novembre 2017, par KudoLayton

  I’m following ffmpeg tutorial in http://dranger.com/ffmpeg/tutorial01.html.

  I have just found that avpicture_get_size function is deprecated.

  So I have checked ffmpeg’s document(https://www.ffmpeg.org/doxygen/3.0/group__lavu__picture.html#ga24a67963c3ae0054a2a4bab35930e694) and found substitute av_image_get_buffer_size.

  But I can’t understand align parameter meaning ’linesize alignment’......

  What is it meaning ?

• Révision 23671 : Utiliser la clé du tableau, pas un index fabriqué.

  13 juillet 2017, par nicolas.dorigny@gmail.com

• Anomalie #3260 (Nouveau) : Problème de dump sur les tables comportants des index de longueur spéci...

  28 août 2014, par b b

  Le contexte est le suivant : http://contrib.spip.net/GIS-4?debut_comments-list=@476655#forum476655

  En résumé, depuis que la table spip_gis contient des index dont la longueur est spécifiée, le système de dump génère une erreur sur ces tables. Après pas mal de recherche, je suis remonté jusqu’à spip_mysql_show_table() (raison pour laquelle ce ticket est déclaré sur le core et non le plugin dump).

  J’ai d’abord étudié ce qui se passe dans base_copier_table() de ecrire/base/dump.php :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/base/dump.php#L536

  À ce niveau, dans $desc_source['key'] la longueur des index n’est pas renseignée. Si on compare le contenu des fichiers de cache des descriptions des tables, on observe que tmp/cache/sql_desc*.txt ne renseigne pas la longueur des index. Alors que tmp/cachesql_desc_dump*.txt est ok, la longueur des index y est présente.

  Du coup, j’en suis remonté à sql_showtable(), et plus précisemment à spip_mysql_show_table() :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L754

  Depuis phpmyadmin, un SHOW CREATE TABLE renvoie bien ce qu’il faut, ex :

  CREATE TABLE `spip_gis` (
   `id_gis` bigint(21) NOT NULL AUTO_INCREMENT,
   `titre` text NOT NULL,
   `descriptif` text NOT NULL,
   `lat` double DEFAULT NULL,
   `lon` double DEFAULT NULL,
   `zoom` tinyint(4) DEFAULT NULL,
   `adresse` text NOT NULL,
   `pays` text NOT NULL,
   `code_pays` varchar(255) NOT NULL DEFAULT ’’,
   `region` text NOT NULL,
   `departement` text NOT NULL,
   `ville` text NOT NULL,
   `code_postal` varchar(255) NOT NULL DEFAULT ’’,
   PRIMARY KEY (`id_gis`),
   KEY `lat` (`lat`),
   KEY `lon` (`lon`),
   KEY `pays` (`pays`(500)),
   KEY `code_pays` (`code_pays`),
   KEY `region` (`region`(500)),
   KEY `ville` (`ville`(500)),
   KEY `code_postal` (`code_postal`),
   KEY `departement` (`departement`(500))
  ) ENGINE=MyISAM AUTO_INCREMENT=24 DEFAULT CHARSET=latin1
  

  Il semble que la regex de la ligne 736 ne match pas la table spip_gis certainement à cause des (500) :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L736

  Et du coup, on bascule sur le plan B, qui ne fait qu’un simple SHOW COLUMNS FROM ne contenant pas l’information de longueur des index :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L765

  Wala où j’en suis ^^ Je ne sais pas si ce comportement est voulu, mais il pose un sacré problème pour les dumps.