Nouvelle fonctionnalité pour FILEBIN

Aujourd'hui, la situation est la suivante:
- FILEBIN_READ/WRITE permet de lire/écrire un seul octet dans/à partir d'une variable de type entier.
- FILEBIN_HEXA_READ/READ£/WRITE lisent/écrivent un nombre variable de caractères en code hexa dans/à partir d'une chaîne de caractères
-FILEBIN_BLOCK_READ/WRITE lisent/écrivent un nombre quelconque d'octets dans/à partir d'un tableau d'entiers à une dimension, à raison d'un octet par élément du tableau

Tout cela a son utilité. Mais c'est extrêmement lent lorsqu'on veut accéder des mots de 32 bits, et, pire, des blocs entiers sur des centaines ou milliers d'octets.

Je propose les commandes et fonctions suivantes:
FILEBIN_WORD_READ N,V : lit un mot de 16 bits (2 octets) dans la variable entière V
FILEBIN_WORD_READ(N) : retourne une valeur entière correspondant à un mot de 16 bits (2 octets)
FILEBIN_WORD_WRITE N,V : écrit un mot de 16 bits (2 octets) à partir de la variable entière V
ou
FILEBIN_INT16_READ N,V : lit un mot de 16 bits (2 octets) dans la variable entière V
FILEBIN_INT16_READ(N) : retourne une valeur entière correspondant à un mot de 16 bits (2 octets)
FILEBIN_INT16_WRITE N,V : écrit un mot de 16 bits (2 octets) à partir de la variable entière V

FILEBIN_LONG_READ N,V : lit un mot de 32 bits (4 octets) dans la variable entière V
FILEBIN_LONG_READ(N) : retourne une valeur entière correspondant à un mot de 32 bits (4 octets)
FILEBIN_LONG_WRITE N,V : écrit un mot de 32 bits (4 octets) à partir de la variable entière V
ou
FILEBIN_INT32_READ N,V : lit un mot de 32 bits (4 octets) dans la variable entière V
FILEBIN_INT32_READ(N) : retourne une valeur entière correspondant à un mot de 32 bits (4 octets)
FILEBIN_INT32_WRITE N,V : écrit un mot de 32 bits (4 octets) à partir de la variable entière V

FILEBIN_STRING_READ N,C,V : lit une suite de C octets dans la variable chaîne V
FILEBIN_STRING_READ$(N,C) : retourne une valeur chaîne de C octets
FILEBIN_STRING_WRITE N,C,V : écrit C octets à partir de la variable chaîne V

Ceci aurait 2 avantages majeurs:
- simplification significative du codage
- gain de temps substantiel en exécution

Techniquement, en Delphi, cela peut se faire par un TFileStream sur le fichier, et un TMemoryStream pour les variables. Très rapide.

+1

Tout ce qui peut rendre les traitements plus court, je suis pour.

C'est une bonne idée, et il n'y a pas de raison que je ne code pas ces nouvelles commandes et fonctions.

Cependant, je ne vois pas très bien la différence entre WORD et INT16 d'une part et entre  LONG et INT32 d'autre part. La différence serait-elle entre entiers et flottants ?
Mais tu parles de variables entières pour chacune des commandes/fonctions avec WORD, LONG, INT16 et INT32.

Merci pour ton intérêt pour ma suggestion, Jack !

Je ai certainement été un peu trop succint, dans ma description. En effet, je parle de variables entières. Pour moi, WORD et INT16 sont des synonymes - on peut choisir l'un ou l'autre. J'ai une préférence pour INT16 parce que c'est plus clair (les notions WORD et LONG n'ont une signification claire seulement pour les adeptes de Delphi ou similaires). Idem pour LONG et INT32.

Dans le cas de INT16, dans mon esprit, la fonction lit deux octets à partir de la position courante et les place dans les deux octets de poids faible d'une variable de type integer de Panoramic, en plaçant des zéros dans les octets de poids fort de cette variable.

Dans le cas des INT32, dans mon esprit, la fonction lit 4 octets et les place dans le même ordre dans les 4 octets d'une variable de type integer de Panoramic.

EDIT

Dans ma DLL, je crée cette fonction:

Code:

{    Codes retour:
         0 = ok
        -1 = erreur en ouvrant du fichier
        -2 = erreur en positionnement
        -3 = erreur en lecture

    infile:    passé par adr(fichier$) avec fichier$ contenant nom ou le chemin avec le nom du fichier à lire
    outstring: passé par adr(s$) avec s$ recevant le texte lu - doit être assez large pour ça !
    start:     adresse de début de lecture, ou lecture à partir de la position courante si start<0
    len:       nombre d'octets à lire
}
function ReadBinaryStringFromFile(infile: pstring; outstring: integer; start,len: integer):integer; stdcall; export;
var
  sStream: TFileStream;
begin
  result := -1;
  try
    sStream := TFileStream.Create(infile^, fmOpenRead);            // ouvrir le fichier en lecture
    result := -2;
    if start>=0 then sStream.Position := start;                    // positionner à l'endroit voulu
    result := -3;
    sStream.ReadBuffer(pointer(pinteger(outstring)^)^,len);        // lire le nombre de caractères
    sStream.Free;
    result := 0;
  except
    if assigned(sStream) then begin
      try
        sStream.Free;
      except
      end;
    end;
  end;
end;

et en Panoramic, je l'appelle de la manière suivante:

Code:

dim res%, s$, f$, start%

open_dialog 1
' f$ = file_name$(1)
' if f$="_" then terminate
f$ = "essai.exe"

dll_on "KGF.dll"
s$ = string$(2000000,"*")   : ' réservation de l'espace
start% = 4096 : ' pour positionner
' start% = -1 : ' pour lecture en continu à partir de la position courante

res% = dll_call4("ReadBinaryStringFromFile",adr(f$),adr(s$),start%,2000000)
'  Ici, s$ contient du binaire qui ne peut pas être traité par les fonctions string de Panoramic.
'  Mais adr(s$) peut être passé à une autre fonction DLL qui traite le contenu de la variable,
'  pour une écriture, par exemple, ou pour une analyse des données binaires.
' Ceci est le but recherché.
end

C'est quasiment instantané. En comparaison, FILEBIN_BLOCK_READ est, disons, un escargot...

Et un dump d'un fichier EXE Panoramic: NouveauFichier.exe. Le code affiche un message avec le code retour de la fonction ReadBinaryStringFromFile qui est 0 s'il n'y a pas d'erreur. C'est ultra-rapide, sachant qu'on lit une chaîne de 2 millions de caractères en une seule opération. Ensuite, c'est le dump de la variable s$, et là, il faut attendre. Mais le but de la démo était la faisabilité et la vitesse de la fonction de lecture par la DLL:

Code:

dim res%, s$, f$

open_dialog 1
f$ = "NouveauFichier.exe"

dll_on "KGF.dll"
s$ = string$(2000000,"*")
res% = dll_call4("ReadBinaryStringFromFile",adr(f$),adr(s$),0,2000000)
message str$(res%)

memo 2 : full_space 2 : bar_both 2 : font_name 2,"courier"
dim i%, k%, a%, c$
for i%=1 to 10000
  c$ = right$("0000000"+hex$(a%),8) + ": "
  for k%=1 to 16
    c$ = c$ + " "+right$("0"+hex$(asc(mid$(s$,a%+k%,1))),2)
  next k%
  item_add 2,c$
  a% = a% + 16
next i%

end

Ca tombe bien, j' aime pas les escargots, je préfère le civet de lièvre...
...un petit détail, à vouloir être plus rapide que lucky luck, tu as oublié de coder l' open_dialog

Je me suis amusé à faire une lecture directe dans un tableau d'entiers de Panoramic. La fonction lit un nombre donné de mots 32 bits dans un tableau e'entiers Panoramic à une dimension, à partir de la cellule (0). Voici le code Delphi de la fonction:

Code:

// lire n mots de 32 bis d'un fichier binaire dans un tableau d'entiers Panoramic
{    Codes retour:
        0 = ok
        -1 = erreur en ouvrant du fichier
        -2 = erreur en positionnement
        -3 = erreur en lecture

    infile:    passé par adr(fichier$) avec fichier$ contenant nom ou le chemin avec le nom du fichier à lire
    outadr:    passé par adr(buf%) avec buf%$ recevant les données lues - doit être assez large pour ça !
    start:    indice de début de lecture, ou lecture à partir de la position courante si start<0
    len:      nombre d'entiers à lire
}
function ReadIntegerArray32FromFile(infile: pstring; outadr: pointer; start,len: integer):integer; stdcall; export;
var
  sStream: TFileStream;
begin
  result := -1;
  try
    sStream := TFileStream.Create(infile^, fmOpenRead);            // ouvrir le fichier en lecture
    result := -2;
    if start>=0 then sStream.Position := start*4;                  // positionner à l'endroit voulu
    result := -3;
    sStream.ReadBuffer(outadr^,len*4);                            // lire le nombre de caractères
    sStream.Free;
    result := 0;
  except
    if assigned(sStream) then begin
      try
        sStream.Free;
      except
      end;
    end;
  end;
end;

Et c'est utilisé comme suit:

Code:

dim res%, buf%(500000), f$, start%, size%, i%, k%, a%, s$

dll_on "KGF.dll"

width 0,800
open_dialog 1
f$ = file_name$(1)
memo 2 : full_space 2 : bar_both 2 : font_name 2,"courier"

start% = 0
size% = 500000
res% = dll_call4("ReadIntegerArray32FromFile",adr(f$),adr(buf%),start%,size%)
message str$(res%)

a% = 0
for i%=0 to 1000
  s$ = right$("0000000"+hex$(a%*4),8)+": "
  for k%=0 to 7
    s$ = s$ + " " + right$("0000000"+hex$(buf%(a%+k%)),8)
  next k%
  item_add 2,s$
  a% = a% + 8
next i%

end

Là encore, je lis 500000 mots de 32 bits, donc 2 millions d'octets. C'est quasiment instantané. Et on trouve le résultat directement dans le tableau.

Klaus, 

la dll est elle à jour sur ton Webdav ?

Non, pas avec ces fonctions de lecture. Je suis en train d'expérimenter des possibilites de lecture/écrirure rapide en binaire et j'essaie de voir quelles sont les possibilités et les limites. Cette dernière fonction ReadIntegerArray32FromFile par exemple, pourrait être une nouvelle commande
FILEBIN_READ_ARRAY32 N,C,A
ainsi que
FILEBIN_WRITE_ARRAY32 N,C,A
avec:
- N étant le numéro du fichier ouvert avec FILEBIN_OPEN_READ
- C étant le nombre de mots 32 bits à lire,
- A étant le nom d'un tableau d'entiers une dimension
ainsi que
FILEBIN_POSITION_INT32 N,P
ou
FILEBIN_POSITION_LONG N,P
avec:
- N étant le numéro du fichier ouvert avec FILEBIN_OPEN_READ
- P étant le numéro du mot à positionner (agit comme un indice dans un tableau d'entiers de Panoramic)

Je sais que je n'avais pas (encore) suggéré ces deux commandes à Jack, mais elles font sens tout aussi bien que celles que j'ai proposées au début de ce fil de discussion. Comme Jack semble ouvert à ces idées, je me suis permis d'expérimenter et de publier ces petits bouts de code, surtout dans l'idée de montrer la faisabilité et le résultat que l'on peut obtenir. Ainsi, la fonction ReadBinaryStringFromFile présentée dans mon post précédent pourrait être l'implémentation de la commande
FILEBIN_STRING_READ N,C,V
que j'avais proposée initialement.

Comme Jack a indiqué qu'il pourrait réaliser ce genre de fonctions, j'attends de voir ce qu'il fait ou va faire, car ça ne sert à rien de réaliser des fonctions qui font double emploi avec de nouvelles commandes. Le but est juste de donner une idée d'implémentation, et, surtout, de mesurer l'intérêt que ces nouvelles commandes potentielles pourraient éveiller chez d'autres Panoramiciens.

Si ces fonctions voient le jour, cela sera un plus en rapidité
pour le traitement des fichiers en binaire, c' est une évidence.

Je suis pour la création de ces nouvelles commandes/fonctions et personnellement je prefère WORD/LONG à INT16/INT32. Mais avant cela, je préfèrerai largement que les nouvelles commandes de LIBRARY soient finalisées!