[Allegro] Zum Thema "Füllzeichen"

Fr Sep 2 11:19:36 CEST 2022

K. Lehmann schrieb:

>> die basis ist 32bit. 64bit-module werden angeboten (ist bei allegro leider kein thema, noch nicht. wann?)

Die für Linux vorliegenden 64er sind folgende: (und liegen im Ordner  downloads)

acon64    
asort64   
avanti64  
import64     
index64 
srch64 
Besonders srch64 wird gepriesen für sein Tempo.

Um 64er Versionen für Windows zu erstellen, müßte ich mir das aktuelle VisualStudio22 besorgen und damit 
alles kompilieren. Das wird zeitlich kaum vor November gehen, aber schau'mer mal.
(Bis dato habe ich immer noch VisualC++ 6-0 im Einsatz. Der Umstellungsaufwand ist nicht einschätzbar.)

B.E.

> Gesendet: Donnerstag, 01. September 2022 um 22:26 Uhr
> Von: "Klaus Lehmann" <lehmann_klaus at t-online.de>
> An: "Diskussionsliste Allegro-C" <allegro at biblio.tu-bs.de>
> Betreff: Re: [Allegro] Zum Thema "Füllzeichen"
>
>  
> Guten Abend Herr Eger,
> danke für Ihre Nachricht.
> Am Donnerstag, 1. September 2022 um 21:19 schrieben Sie.
> Ihre Nachricht finden Sie am Ende dieser eMail.
> 
> > Hallo Herr Lehmann,
> >> > Das ist auch einer der Gründe, weshalb ich die neueren Allegro-Kernsysteme (> V31.10 
> >> > Dezember) bei meinen Kunden nicht einsetze.
> >> das ist natürlich eine böse entscheidung.
>                           ~~~~~~~~~~~~~~~~~
> ja,.... das war ein zu(?) schneller satz von mir.
> 
> 
> nur mal so nebenbei geplaudert:
> aber: ich hatte neulich ein problem bei meiner aktuellen version von allegro-cjk. (utf8, mit china,japan und korea)
> eine bibliothek lief sehr zufriedenstellend mit einem ca 8-12 jahren alten allegro von mir. 
> das könnte in ihre "bedingung" mit (> V31.10 > Dezember) reinpassen.
> dann: es gab zusammenbrüche, es gab datenverluste. 
> 
> ursache: sie migrierten von 32bit-w7 auf 64bit-w10. 
> [achtung: die migration fand erst 2022/02 statt! sic!]
> 
> 
> die erste erkenntnis: 
> das alte allegro machte unter den neuen bedingungen nicht mehr mit.
> hätte die bibliothek win7-32bit weiter gehabt, wäre es nicht zur zweiten erkenntnis gekommen:
> 
> 
> die zweite erkenntnis: 
> diese zeile aus einer api, die ich (mit h.allers vor 12 jahren) entwickelt habe, hatte eine eingebaute sprengfalle:
> #99W                                      $$ha/28.8.2010
> #-ó                                       $$ha/28.8.2010
> !ux1 { 8 "|3" } P{" *"}                   $$ha/28.8.2010+6.12.2010
> #ux1 y0 dx2 e"#utr" f" " F" " =x2 e0      $$ha/28.8.2010
> !ux2 { 8 "|3" } P{" *"}                   $$ha/28.8.2010+6.12.2010
>    #ux1 +ó y0 dx1 b"#utr" =x1 e0             $$ha/28.8.2010
>    ~~~~~~~~~~~~~~~~~~~ wenn diese zeile aktiv ist, knallt es! (indexvorgang2 bricht ab! 2022/2)
> #utr dtr dx1 dx2 e0                       $$ha/28.8.2010
> #+#                                       $$ha/28.8.2010
> 
> aktiviert man die zeile, die bis 2022/2 gültig, wars das. 
> niente. meister kaputtnick hatte die herrschaft übernommen. ich hatte monatelang nach dem fehler gesucht...
> 
> 
> 
> > Ja, manchmal bin ich böse ;-)
> > Man versucht halt Stabilität/Aufwand zu maximieren.
> 
> > Viele Grüße
> > Anando Eger
> > Erfolg ersetzt alle Argumente.
> na klar. voll einzusehen.
> 
> 
> aber: ich habe bei wolfgang grein (kennt ihn noch jemand?[er war mein mentor]) erlebt, was das (sein!) beharren auf eine search.exe (16bit) für schlimme auswirkungen hatte.
> er war einfach zu "faul" (wolfgang vergebe mir!), seinen code so anzupassen, daß es mit moderneren search.exe zusammenarbeiten würdee. und wir wissen alle, was mit 16bit passierte.
> keiner kann es sich heute leisten, ein win10-32bit zur verfügung zu haben. es muss 64bit sein!
> 
> deshalb ist bei mir die maxime: auf 16bit hört keiner mehr.
> die basis ist 32bit. 64bit-module werden angeboten (ist bei allegro leider kein thema, noch nicht. wann?)
> ich gehe davon aus, daß allegro-32bit für die nächsten 5-10 jahre arbeiten wird.
> 
> 
> grüße, ihr klaus lehmann
> 
> ps: ich hätte sehr gerne ein 64bit allegro.
> 
> um die 2GB-grenze bei adx und stl-dateien zu akzeptieren, muss ich bei sehr(!) großen datenbank gewaltige klimmzüge machen. noch schaffe ich sie.
> 
> hier ein kleiner einblick:
> imd.adx                                                     │1365475328│13.11.2020│ 18:1816:42║
> imd.aex                                                     │ 311517184│13.11.2020│ 18:1816:42║
> imd.afx                                                     │ 455438336│02.12.2020│ 13:0411:58║
> imd.agx                                                     │ 100964352│02.12.2020│ 13:0411:58║
> imd.ahx                                                     │  34242560│02.12.2020│ 13:0414:42║
> imd.aix                                                     │   2531328│02.12.2020│ 13:0415:30║
> imd.ajx                                                     │ 340926464│09.11.2020│ 14:4223:25║
> imd.akx                                                     │ 357294080│14.02.2021│ 13:1323:25║
> imd.alx                                                     │ 113082368│09.11.2020│ 14:4723:25║
> imd.amx                                                     │ 317595648│09.11.2020│ 14:5010:22║
> imd.anx                                                     │ 110241792│09.11.2020│ 14:5119:55║
> imd.aox                                                     │ 238284800│09.11.2020│ 14:53
> 
> würde ich die a?x-dateien nicht aufdröseln, würde ich auf eine größe 3,7GB bei der adx-datei kommen. bei 2GB und eben 32bit-allegro ist aber derzeit schluss! ernsthaft!
> für die letzte fassung der imdb-allegro habe ich 9,0 GB an ald's.
> nagut, solche allegro-datenbank hat und braucht nicht jeder ;-)
> 
> naja: ich könnte mir schon zwei anwendungsbereiche für bibliotheken vorstellen: die DNB und ZDB als vufind-katalog! eben MIT marc-export.
> warum? weil sie offiziell von der (bescheuerten) DNB keine marc-export bekommen, und ebensowenig von der (bescheuerten) ZDB bekommen. das war mal.
> wenn sie die datensätze offiziell ansehen, haben sie keine vorstellung vom echten marc-code, aus dem die datensätze gebaut sind.
> 
> tip: bei k10plus haben sie manchmal/öfter glück! was die ansicht betrifft. es ist eben k10plus. und das ist nicht als positivum gemeint.
> meine neuen server werden irgendwann in der lage sein, komplett dnb und zdb abzubilden. aber nicht zugänglich für die öffentlichkeit (auch nicht für "meine" bibliotheken!).
> 
> 
> 
> -- 
> Mit freundlichen Grüßen,
> Ihr Klaus Lehmann
> http://allegronet.de * eMail: allegronet at t-online.de * 
> phone: 03528-452 807(fax 809) * mobil: 0171-953 7843 *
> allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1 *
> zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden *
> zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760 *
> * Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
> * Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
> * 2011-22: Sponsor: Peter-Sodann-Bibliothek
> * 2013-14: Bolero 32bit.+allegro-zdb: endlich. + eBooks
> * 2015-16: allegro-imd. Die weltgrößte(?) Filmdatenbank
> * 2017-22: Exporte. Marc und Co. Marc ist sehr different
> * 2019-22: All for VuFind! The perfect export into marc21
> * 2020-22: kohanet.de. Alternativen zu allegro-C und allegronet.de
> 
> 
> 
> 
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro
> 
> Um sich von dieser Liste abzumelden, klicken Sie hier: mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe
> 
> To unsubscribe from this list, click here: mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe
>