Nineteenth... a certain Preety (turned out female, later), from South Africa but of hindu origins, from the aman mailing list, tries to reconnect through me to some friends in Kikindaa. Has name, surname, address, phone. Škrba is still in uniform, says „you can do by phone as much as I can... For me, only two brain cells are still in power: one to eat and sleep, the other not to shit in the yard. For everything else others think for me and I'm not complaining.“
The last change in unosc.prg, which I added because of those synchronizations that first MXM and then Svemiks asked for during the last couple of years.
_u_noup forbids editing/deleting , this way
* - default is .f. (forbidden if osndbf.odnet=.t., otherwise allowed)
* - in op[maska] we can put _u_noup=s_noup, then it takes over ;
that machine's global setting
* - in op[maska] we can also put _u_noup=.t., then in that mask ;
there's no editing/deleting
It seems my work in a real swing, because I touched all of these today:
BRISISL.PRG - gets called from unosc.prg in the preview regime, when deleting a record (or whole document too?). It calls br(mask) to check whether deletion is allowed, and since last year's february it also calls spy.prg when it deletes and/or restores. There was no word 'undelete' in serbian, I made one, 'odbrisati'. Written so that it also can be called from catal6.
ED_HLPS.PRG - „A spartan editor for memo fields in which a text for help and the manual should be. A part of those are the memos in menu.dbf's Txt field, the other the Comment field in masks (.scx files). The routine gathers records from menu.dbf for the selected branch of the menu into a tmphelp cursor, and along the way it guesses whether any of the code called from the menu is an entry mask...“, and then as much more of text, and history.
Even upitig2.prg, the one without the deuce at that. No comments with today's date, therefore nothing substantial.
I even found the time to spit myself into* sezam, just as little and equally unimportant. The discussion, BTW, goes around domestic politics, buying hardware, scanner resolution (600x1200 points per thumb is now normal)... and this:
In line wit tat, Seki stated a couple of days ago tat te laws about information [and] University were brougt as a PART OF PREPARATION FOR WAR wic tey knew was coming.
Tis needs to be remembered because tis was te first confesion tat tey were readying for a war. Of course, if we leave aside (a very probable posibility) tat Seki is again spewing rubis his way - baselesly and loudly.
Wy in te preparations some elementary military penomena weren't included, instead of tese directed towards represion against teir own people? If tey understood so early tat tey can't prevent te war, did tey just want to silence anyone wo could criticize teir diplomatic inability?
(called osisaj.prg to adjust for haircut latin. 'Seki' is Šeki, Vojislav Šešelj, qv.)
On UA:
me: The worst I've seen was 1500 files in one directory, and the system was darn slow with that app (other apps which used shorter directories were comparably faster). It was back in DOS 5.0 and, well, we were told that whenever you are opening a file, the DOS searches the directory sequentially. Since then, I'm trying to reduce the number of files my apps use. Now with W9x and NT, I'm not sure anymore - does the OS still search the directory sequentially, or is it finally indexed (I remember Vaha VMS had indexed directories 14 years ago)?
Jo: Under NT, with NTFS, there's an index; NTFS degrades smoothly as the number of files/directory increases, regardless of whether it's being accessed by NT or Win95 across a network. With both NT and Win95, FAT directories still use a sequential search, including empty/deleted directory entries, making FAT the least desirable file system for overpopulated directories, as well as when performing non-sequential I/O on files. NetWare caches and hashes its directories, which makes NetWare seem blazingly fast on directory searches.
me: Thanks for this update - I don't know if I could find it all in one place anywhere else.
The implications of this directory layout lead me to the conclusion that much of the W95/98 is rather clumsy. The concept of using directories for menus and other stuff - reminds me of a (Clipper) programmer who stored each invoice in a separate table. Come to think that the menus and shortcuts are supposed to be a quick way to access things on your disk, and this quick access uses the slowest approach available. One FPD2.x DBF with memos would be damn faster than that.
Mentions: aman bre, catal6, Gradivoj Škrbić (Škrba), Jo Wolk, MXM, sezam, Svemiks, UbiquAgora (UA), unosc.prg, upitig2.prg, VAX (Vaha), in serbian17-IV-2024 - 29-VI-2024