Mensajes

Recuerdo allá a comienzos de los 90, cuando salieron los primeros discos duros de 1Gb. y que los tecnófilos (esos incondicionales bocachanclas que hablan más desde el corazón que desde la corazón), siempre absolutistas sentenciaron que: "Cuando se alcancen discos del tamaño de 1Tb. las personas podrán tener toda su vida ahí recogida."... como aquella frase del Señor Guillermo Puertas allá a comienzos de los 80, respecto de la RAM: "64Kb. debieran ser suficiente para todos."

Si yo fuera presidente de algún gobierno, una de las primeras leyes que aprobaría sería que:
- En los contratos, prevalece la letra grande, cuanto más pequeña más irrelevante debe entenderse que es su contenido y así deberá interpretarlo un juez.
- Al mismo tiempo limitaría el número de páginas que firman un contrato. Un contrato no puede tener el tamaño de un libro, ni siquiera el de un cómic, si es imposible explicar las condiciones en tal que 4 páginas, (para mi) hay claras intenciones de ofuscar el entendimiento del mismo.
- Limitaría también el número de claúsulas, tal vez algo como 30... si un contrato debe tener 200 claúsulas será imposible saber si en algún momento se incumple alguna, porque nadie podrá recordar 200 cláususlas de cada contrato que firma, claramente existe intencionalidad de que el firmante se vea incapacitado de cumplirlo y que por tanto quede siempre a criterio casi en cualquier momento decidir si resuelve el contrato como le dé la gana...
- También impediría usar términos cualesquiera, obligaría a que los jueces y abogados crearan un 'diccionario' de términos tal que quede acotado su significado y éste sea único y entendible por cualquier persona, como eso llevaría un tiempo, terminado tal 'diccionario',  ningún contrato podría incluir términos complejos que no queden recogidos en ese diccionario, y cada uno de ellos, los usados en el mismo, debeieran constar en un índice al final del contrato y el número o referencia con que aparece en el diccionario...

Tenemos más leyes que poblaciones y con cada gobierno, cada año, surgen nuevas leyes, pero rara vez se elimina alguna o se reúnen varias en una sola misma... Se puede apostar a que no existe ni un solo juez ni abogado que se conozca todas las leyes... pero curiosamente nunca ha aparecido ni tiene visos de aparecer una ley que fuerce a que las propias leyes sean claras de entender... Entonces si los propios legisladores son oscuros con leyes inteligibles y refrencias cruzadas constantemente, cómo no van a serlo los términos de los contratos de empresas que se guían exclusivamente por cuestiones económicas...

Eso se llama "refundición".

Primero debes crear el array de salida con el tamaño de ambos (no se pide retirar repetidos).

Luego debes tener en cuenta el tamaño de ambos arrays, cuando tienen el mismo tamaño puede parecer más sencillo obviamente, pero no es el caso.
Entonces se crea una variabe que actúa control de fin, que sucederá cuando uno de los arrays llegue al final, lo operación continuará luego poniendo tras el final el resto del segundo array si queda algo. Date cuenta pués que ese 'siq queda algo' no depende del tamaño del array si no de los valores que contenga cada uno.

Código [Seleccionar] Expandir


entero j, k, n, sizeA, sizeB

sizeA= size(arrayA)
sizeB = size(arrayB)

entero arrSalida(0 a sizeA + sizeB -1)


Hacer mientras (limite = 0)
   Hacer mientras (arrayA(j) => arrayB(k))
       arrSalida(n) = arrayA(j)
       n +=1
       j +=1
       si (j> sizeA)
           limite=1        // señalaría que el arrayB debe depositar lo que reste en salida
           // podría hacerse aquí, pero queda más claro si se hace fuera de ambos bucles.
           salir del bucle
       fin si  
   repetir  
   
   si limite = 0
       Hacer mientras (arrayB(k) > arrayA(j))
           arrSalida(n) = arrayA(k)
           n +=1
           k +=1
           si (k> sizeB)
               limite=2        // señalaría que el arrayB debe depositar lo que reste en salida
               // podría hacerse aquí, pero queda más claro si se hace fuera de ambos bucles.
               salir del bucle
           fin si  
       repetir
   fin si
repetir

Si limite = 1
   bucle para k desde k hasta sizeB
       arrSalida(n) = arrayb(k)
       n +=1
       k +=1
   siguiente
sino // limite = 2
   bucle para j desde j hasta sizeA
       arrSalida(n) = arrayA(j)
       n +=1
       j +=1
   siguiente
fin si


p.d.: Ascendente o descendente implica cambiar los operadores de comparación, tal como yo los he puesto se ordenan de mayor a menor...

Disponer de 'usuarios entusiastas' dispuestos a perder su tiempo en probar programas excesivamente defectuosos, puede (y seguro lo hará), reducir costes a Mocosoft en el testeo de los mismos, peor obivamente, nunca será lo mismo un usuario entusiasta que un profesional cualificado, para determinar problemas y sus posibles causas.

En fin, yo creo que el servicio ese de testeo, debiera ser exclusivamente para probar y encontrar fallos irrelevantes que se haya escapado al propio equipo de testeo en la propia Mocosoft, es decir en versiones libres ya de cosas 'garrafales' como fallos de instalación que dejen colgado equipos, que ni puedes iniciar el sistema...

La amenaza de 'publicar.... qué'?.
Habrá gente que tenga fotos porno propias o de su pareja, en su PC... seguro, pero dudo mucho que sean tantas como para que la estrategida de amenazar con publicar sea correcta...

...por otro lado, no veo a un hacker que expande su virus por doquier reenviándose ficheros, por cuestiones lógicas: Ni es razonable buscar para localizar contenido comprometedor, ni es práctico reenviarse todo el contenido (del usuario) de un disco duro... y mucho menos por cada intrusión... Salvo que el hacker detrás de todo ello fuera el gobierno chino, dudo que un grupo de hackers tuviera capacidad para almacenar el contenido de tanto disco duro, ni tiempo para hacerlo y eso sin contar lo que levantaría sospechas todo ese envío masivo... pero claro, no faltará quien pique a causa de las amenazas.

Jo... parece que el propio 'redactor' del artículo, lo redacta o traduce sin entender lo que escribe...
Escribe : "en un vidrio de cuarzo de 75 por 75 centímetros y 2 milímetros de grosor", luego sale una chica con la muestra en la mano, de ser, serán 7'5cm...
Ya me decía yo, que qué utilidad podría tener guardar algo de 75x75cm. cuando hasta manejarlo sería complicado y siendo de 2mm de grosor, hasta frágil.

Aunque la idea es de interés creo que es muy verde aún. Un cristal de 2 mm, aunque sea de cuarzo sigue siendo demasiado frágil
...y el tamaño no es distinto de un CD-DVD, lo que equivale a decir que la tecnología del CD, podría aplicarse (con las tranformaciones necesarias), para grabar DVDs que sean de un material más durable que el plástico de dichos discos. ...después de todo la tecnología base es la misma, grabar con una láser, produciendo deformaciones físicas en el soporte. En fin, no lo veo tan novedoso...

Con esta impresora 3D puedes imprimir tus propios cables de fibra óptica

Efectivamente.
Como todo el mundo sabe, todos necesitamos en casa cables de fibra óptica diariamente o no llegamos al día siguiente...

¡Se acabaron los problemas del ciudadano con esta impresora!

...y dejar tu código disponible a Microsoft?. No gracias...

Ahora abre el buscaminas, no hay huevos.

Si, hombre... basta que te lo tomes como una partida de ajedreaz de esas por correspondencia...  cada día/semana un movimiento.

[Function "SB"]

Antes de nada, perdón, pués yo puse un mensaje (que deben haber borrado) de "Esto es Spam", por la simple razón de que solo había 2 líneas de texto y un enlace (apuntando fuera del foro), además juraría que vi repetido el mensaje en otro lado... Sin más explicaciones, ni ningún simple ejemplo de nada, sonaba claramente a Spam.


Mirando así por encima, veo cosas muy mejorables.. por ejemplo la simple función de invertir una cadena de texto:

Código [Seleccionar] Expandir


Function ReverseStr(_cIn)
* Invierte el orden de los caracteres de una cadena.

Local _rStr := ""
Local _nB00 := 0

For _nB00 = Len(_cIn) To 1 Step (-1)
_rStr := (_rStr + SubStr(_cIn, _nB00, 1))
Next _nB00

Return (_rStr)


Concatenar una cadena es algo que no debe hacerse más de 1 ó 2 veces para obtener un contenido, por que cada concatenación exige buscar memoria libre con la suma total de caracteres y copiar ahí las partes a unir... luego en un bucle de por ejemplo 100 caracteres invertir esa cadena supone crear 100 veces una cadena y copiar cada vez las partes que la componen, total para ir añadiendo cada vez un solo carácter respecto del contenido previo...

Crea una cadena del largo total (cuando se conoce) o más (si no se conoce y al final se devuelve el 'substring' de solo la parte ocupada)... "_rStr" será igual de larga finalmente que "_cIn", luego procede al comienzo hacerla del mismo tamaño.
... y vas tomando caracteres del final de la cadena y poniéndolos al comienzo, o al revés, los tomas del comienzo y los vas poniendo al final retrocediendo. Así a lo sumo creas solo 2 veces la cadena, independientemente del largo que tenga.

Una forma sencilla de probar ambas funciones (la que tienes y la que tendrías que rehacer), sería usar una cadena de por ejemplo 100Mb. y comparar tiempos, en la que te falta por hacer (la óptima), no llevaría más de unos segundos, en la que tienes posiblemente varios minutos (no sé si bastarían 20)...




Cansa ver la forma en que nombras las variables locales y parámetros:
La barra baja "_cStr", suele usarse en los lenguajes para:
- Separar visualmente palabras en identificadores largos, como en: "Precio_Articulo".
- También para unir 'gramáticamente' el nombre de un objeto al nombre de un evento, como en: "Precio_Changed", existiendo un objeto llamado "Precio" que pertenece a un tipo de datos que tiene un evento llamado "Changed".
- Microsoft, cuando finalmente dió facilidades para crear las propiedades autoimplementadas (yo mismo solicité esa característica... hace ya un chorro de años), usa precisamente la barra baja al comienzo del nombre con el mismo nombre de la propiedad para dar respaldo al campo que ha de mantener el valor de la propiedad, dando así oportunidad al usuario de no usar nombres en tal forma, para evitar errores por duplicidad de declaraciones, es una buena alternativa peor para usar exclusivamente en la parte del compilador, no para que un usuario deba enfrentarse a nombres así formados.

Sugiero que como mínimo remplaces esa barra baja por algún carácter legible... por ejemplo para las locales: "lcStr", para los parámetros: "pcStr", para las locales a nivel de módulo: "mcStr"... etc...
Fíjate que incluso leerlo obliga a decir "barra baja cStr", una vez no importa, pero por cada una es requetecansimo... intenta leer tu propio código para que otro lo copie a medida que te oye, y entenderás el absurdo. Y todas las excusas que te inventes, como indicarle de antemano que es 'una regla', sigue siendo absurda... cambia de interlocutor y verás que resulta absurdo explicarle a cada interlocutor una regla, innecesaria... porque para esos existen las letras del abecedario.. son legibles ocupan lo mismo y dispones de 26 mayúsculas y 26 minúdculas... si tienes una regla para señalar que "los nombres d evariables en parámetros las comienzo con 'p', es una regla que no hay necesidad de explicar a nadie, porque 'pcStr', podría llamarse de cualquier otra manera todo el mundo entenderá que hayas elegido ese nombre por alguna razón.

...de todos modos, es siempre preferible poner nombres significativos a las variables (significativas, los parámetros lo son, las variables de tipo contador por ejemplo no y para ellas les baste j, k, t, n, v, etc...).
...en el mismo sentido los nombres de la mayoría de funciones son amorfas... si el códiigo es para tí, no tiene más importancia, tu sabes 'tus reglas', pero si ofeces tu código a otros, complicas innecesariamente las cosas... de qué sirve poner debajo luego un comentario de lo que hace la función, cuando el propio nombre de la función debería sugerir bastante claro lo que debe hacer...
ejemplo:
Tu nombre: Function "SB"
Lo adecuado: Function "StringToBase36"
O como mínimo: Function "StrToB36"



Otro ejemplo de ineficiencia es ese par de funciones de conversión de ASCII a base 36 y viceversa

Código [Seleccionar] Expandir


Function SB(_cIn)
* Conversor de cadenas de caracteres a cadenas en Base-36.


Local _SB := ""
Local _cTemp00 := ""
Local _cTemp01 := ""
Local _nTemp00 := 0
Local _nB00 := 0

For _nB00 = 1 To Len(_cIn) Step 1
_cTemp00 := (_cTemp00 + AS(Str(Asc(SubStr(_cIn, _nB00, 1)) + 256), 3, (-1), 48))
Next _nB00

Do While (Len(_cTemp00) > 0)
_cTemp01 := Left(_cTemp00, 9)
_nTemp00 := (Val(_cTemp01) + 10^9)
_SB := (_SB + NToC(_nTemp00, 36))
_cTemp00 := Right(_cTemp00, (Len(_cTemp00) - 9))
EndDo

Return (Lower(_SB))



Function BS(_cIn)
* Conversor de cadenas en Base-36 a cadena de caracteres original.


Local _BS := ""
Local _cTemp00 := _cIn
Local _cTemp01 := ""
Local _cTemp02 := ""
Local _cTemp03 := ""
Local _cTemp04 := ""
Local _nTemp00 := 0
Local _nTemp01 := 0

Do While (Len(_cTemp00) > 0)
_cTemp01 := Left(_cTemp00, 6)
_nTemp00 := (CToN(_cTemp01, 36) - 10^9)
_cTemp03 := AllTrim(Str(_nTemp00, 9, 0))
_nTemp01 := IIf((Len(_cTemp03) > 6), 9, IIf((Len(_cTemp03) > 3), 6, 3))
_cTemp04 := AS(_cTemp03, _nTemp01, (-1), 48)
_cTemp02 := (_cTemp02 + _cTemp04)
_cTemp00 := Right(_cTemp00, (Len(_cTemp00) - 6))
EndDo

Do While (Len(_cTemp02) > 0)
_cTemp01 := Left(_cTemp02, 3)
_nTemp00 := xVal(_cTemp01)
_BS := (_BS + Chr(_nTemp00))
_cTemp02 := Right(_cTemp02, (Len(_cTemp02) - 3))
EndDo

Return (_BS)


De entrada el código es tortuoso,  mareante  y pecas de nuevo con concatenaciones...
Cuando una conversion forma parte de un proyecto, forozoso es, crear sendos arrays para convertir a y desde usando un simple bucle con apenas 1-4 líneas dentro del bucle, tanto para la codificación como para la decodificación...

Incluso en el caso de tener que hacer variadas conversiones tal que no resulte adecuado tener tablar para cada base usada, entonces procede in situ hacer la conversión de forma matemática (división y módulo para codificar y multiplicación y suma para decodificar).
Siempre que se pueda es preferible crear arrays para una traducción rápida, ya que luego el compilador, viendo que tiene un bucle y un array, tratará la direcciones con registro de índice, lo que acelerará las conversiones, pués evita calcular la dirección absoluta para cada índice del array con multiplicaciones...


Encuentro iguales problemas de inficiencia en muchas otras funciones...



También juraría que las funciones "SHCrypt" y "SHDeCrypt" son idénticas... Procede hacerlo más coherente, una sola función basta, puede llamarse "Crypt" y que acepte un parámetro adicional con valor buelano: Si FALSE=SHDeCrypt y si TRUE=SHCrypt, aunque como no hay diferencias en lo que hace da igual.
Otra forma si prefieres mantener los nombres, es dejar una sola funcion, y la otra compleamente vacía se remite simplemente a invocar a la que tiene el código... (porque hacen exactamente lo mismo, solo cambia el nombre de la función).

Además en esa función de cifrado veo muchos 'modulo', pero no veo ningún 'xor'. Ya te digo por descontado que funciones de cifrado basadas exclusivamente en operaciones aritméticas, son proclives a generar patrones reproducibles de los que aprovecharse. Incluso teniendo operaciones 'xor' si no se controlan adecuadamente también están sujetas a lo mismo, como le pasa por ejemplo al algoritmo RC4.

...
En fin, solo he mirado el fichero "S-Hash.Prg" y si no me gusta lo que veo, no creo que el resto vaya a ser distinto...



p.d.: He tenido que retirar las etiqeutas GEsHI, porque al parecer duplica el contenido cuando el lenguaje es "visualfoxpro", y se ve mal...