Koszonom Szapinak gyors es korrekt valaszat.

En is probalkoztam a makro atemelesevel, csak en nem a
     Set WordApp=CreateObject("Word.Application")
megoldassal, hanem a
     Set Doksi = GetObject("c:\Program Files\Microsoft
     Office\Sablonok\Normal.dot")
valtozattal porbalkoztam, sajnos hasonloan eredmenytelenul. Mindig a '438'
-as hibát kapom, 'Az objektum nem támogatja ezt a tulajdonságot vagy
metódust'. :( Valoszinuleg a Word makroban olyan objektumok is vannak,
amiket Accessbol nem lehet kezelni.
Ezert gondoltam, hogy csak a Word makrojat kellene meghivni.
Szapi masodik javaslata, ami sokkal egyszerubb is
     wordApp.Run "Normal.NewMacros.Makro1"
, kicsit mar kozelebb vitt a megoldashoz. :))) Meg csiszolgatni kell, de a
segito lokest megadta.
Koszonet erte!

Udv

Balazs

Az rtin szerint  ) azt irta, hogy:
>
> Sziasztok!
>
> A kovetkezo gondom van. Adott egy hatalmas C++ program Linux alatt, amit
> nem en irtam, viszont ki kellene javitanom. Segmentation fault-tal szall
> el a malloc.c-ben, 2.2-es glibc mellett. Gondolom, valahol felulirja a
> malloc valami adatat, amitol a malloc behal. Van valami otletetek, hogy
> hogyan lehet megtalalni a bunost? A teljes kodot atnezni, megerteni, es
> kijavitani remenytelennek tunik.

A glibc-ben van egy malloc, aminek a hasznalatahoz include-olni kell az
stdlib.h-t. Ha a programban van egy malloc.c, akkor sajat malloc-ot
hasznal? Legalabb ezt a file-t meg kene nezni, hogy mit is csinal. Aztan
van pl. egy ElectricFence nevu konyvtar, amit ha hozzalinkelsz a
programhoz, akkor kiszurja, hogy hol ir a program olyan helyre, ahova
nem kene. Vagy legalabb megprobalja kiszurni :-)

				Bye,NAR

Sziasztok!

A kovetkezo problemam van:

Egy progit kene irnom Delphiben, ami SQL-szerveren keresztul eri el az
adatbazist. Erre a celra az InterBase 6 megfelelne, mivel ingyenes. A gond
csak az, hogy D.-bol egy 3.0-s standard van legalisan, es azon kene
megoldani a dolgot, de azzal C/S alkalmazast nem lehet irni.  Q1:
Letezik-e olyan free komponens, amivel a standard verzio kiegeszitve kepes
a kliens/szerver megvalositasara?

Q2: Ha nem, a professional elegendo hozza, v. enterprise-ra van szukseg?

Mas:
- Siman a BDE-t hasznalva ha egy adatbazist modositok, akkor mas
felhasznalo eleri kozben az adatbazist?

- Csak olvasasra, v. tudja irni is (kiveve persze a modositas alatt levo
rekordot)? (Magyaran a lockolas rekordszinten valosul-e meg?)

- A modositas utan a tobbi kliens ertesul-e rola, hogy modosult a
rekord? Es ez rendszerfuggo-e?
(Meg regebben Novell Nw. Light alatt voltak negativ tapasztalataim ezzel
kapcsolatban: a file meretenek novekedeserol csak akkor vett tudomast,
ha lezartam a file-t es ujra megnyitottam; ugyanez rendes Novellel
tokeletesen mukodott, a kovetkezo file-hozzaferesnel mar az aktualis
allapotot latta ujranyitas nelkul is.)

Elore is koszi.

Rocky

Hi!

A megfelelő pszeudo véletlen számok tökéletesen elegendőek játékok, vagy
Monte-Carlo megközelítésű algoritmikus problémák megoldására, mert
gyorsak, és jó paraméterválasztás esetén a ciklusidejük is elegndően
nagy. De eredetükből fakadóan valójában determinisztikusak. Ez csak akkor
jelent problémát, ha rejtjelezéses rendszerekben alkalmazzák, ahol
_kriptográfiailag_ erős véletlen számra lenne szükség. Sajnos volt már rá
nem egy példa (pl. Netscape 1.0), hogy ezt egy rand() hívással oldották
meg, ami ugye pszeudovéletlen. Ha meg-seed-elik a pontos idővel, akkor az
még bőven kitalálható, ha mondjuk a generálás ideját a támadó egy perces
intervallumba szűkítheti könnyedén brute-force támadást kivitelezhet.

Javít a szitun, ha ún. "pancsolt" véletlen számot csinálunk, amibe
belevesszük az éppen szabad memóriát, futó processzek számát, stb., de
lényegében ez is kitalálható. Nem szabad kriptográfiailag erősnek
tekinteni.

Ezen javíthatnak a hardware-es véletlen generátorok, melyek termikus
zajból, vagy más kaotikus fizikai folyamatból (levegő
turbulencia) merítenek véletlent, de még itt is vigyázni kell. A Marosi
István által említett DieHard teszten (ami több véletlen tesztet futtat le
a kapott alapanyagon) bizony van amelyik nem megy át.

>Felado :  [Non-Profit Organization]
>Temakor: Re: Veletlenszam_gen ( 12 sor )
>
>On Fri, Feb 21, 1964 at 11:05:00AM +0000,  wrote:
>Korabban volt rola szo, hogy az Intel processzorai kepesek
>lesznek majd felvenni a termikus zajokat is. Ez mar olyan
>veletlen volna, amit igazan semmikeppen sem lehetne meg
>megtippelni sem.

Ne csak CPU-ra gondoljatok. Pl. az i810 chipkészlet tartalmaz integrált
hw-es random generátort. Igaz, nem tudom milyen erőset.

Egy biztos, és ezzel mindenkinek szembe kell néznie: a kriptográfiailag
erős véletlen számok generálása egyre fontosabbá válik, mert kripto
alkalmazások megtörése múlhat azon, hogy pl. hogyan generáljuk a kulcsot.

Elnézést a szájmenésért.

Üdv!

--
tocsa

Szia sorstárs!

>Felado :  [Hungary]
>Temakor: segfault a malloc.c-ben ( 13 sor )
>
>A kovetkezo gondom van. Adott egy hatalmas C++ program Linux alatt, amit
>nem en irtam, viszont ki kellene javitanom. Segmentation fault-tal szall
>el a malloc.c-ben, 2.2-es glibc mellett. Gondolom, valahol felulirja a
>malloc valami adatat, amitol a malloc behal. Van valami otletetek, hogy
>hogyan lehet megtalalni a bunost? A teljes kodot atnezni, megerteni, es
>kijavitani remenytelennek tunik.
>
>Barmilyen segitseget koszonettel veszek.

Nemrég küzdöttem ilyennel, nem irigyellek. Kiderült, hogy az ilyen debugot
a glibc maga is támogatja. Felraktam a glibc-dev-et, és a glibc-doc-ot.
A glibc-doc hatására nézd meg az "info libc"-t, és ott olvashatsz a
siganlokról (SIGSEGV pl. ugye), másrészta  memória kezelésről (malloc,
realoc, free lelkivilága, xmalloc és xrealloc wrapper függvények, ...).

Ha még nem ismernéd a gdb-t, akkor "info gdb".

Ezen felül meg következőket tegyed:
A programkódba include-old be a mcheck.h-t, és legyen az egész program
első utasítása az mtrace(). A program fordításakor használd a -lmcheck
kapcsolót a linker számára. Debuggernek ott a fapados gdb. A program
fordításakor add hozzá a -g kapcsolót, hogy generálódjona  binárishoz
debug info is, de legjobb a -ggdb, mert az meg gdb specifikus debug infot
is nyomat, így könnyebben debugolhatsz makrókat, stb.

Ezzel még mindig nincs vége!
Definiáld a MALLOC_CHECK_ konstanst 1-re a fő include fájlban, és állítsd
be a MALLOC_TRACE környezeti változót egy file-ra. Ebbe file-ba kerül
minden malloc/realloc/free utasításról egy log a progi futása során.
Ha valami gond van, akkor a gdb leáll, és ha a libc tud segíteni, akkor az
előbbi intézkedések hatására képes megállapítani, hogy:
 - block freed twice
 - memory clobbered before allocated block
 - ...
Bővebbet backtrace-el, stb. tudsz megállapítani

Ezen felül ott van az a log file, ami ember számára áttekinthetetlen, de
az mtrace parancsnak megadod paraméterként, és az kianalizálja neked.

Hát röviden ennyi.

További lehetőségek:
strace
dmalloc, ccmalloc
grafikus gdb frontendek (nem sokat segíthetnek)

vagy egy érdekes ötlet:

java átírni (C++-ból nem olyan vészes), ott kidebuggolni, majd java2c-vel
C-t csinálni, állítólag még a garbage compactort is készít.

Jelenleg hasonlóval küzdök, ezért nincs is nagyon időm bővebb segítséget
nyújtani, olvasgasd jól az info és man oldalakat.

Good luck!

--
tocsa

On Sat, Feb 22, 1964 at 06:05:05AM +0000,  wrote:
> A kovetkezo gondom van. Adott egy hatalmas C++ program Linux alatt, amit
> nem en irtam, viszont ki kellene javitanom. Segmentation fault-tal szall
> el a malloc.c-ben, 2.2-es glibc mellett. Gondolom, valahol felulirja a
> malloc valami adatat, amitol a malloc behal. Van valami otletetek, hogy
> hogyan lehet megtalalni a bunost? A teljes kodot atnezni, megerteni, es
> kijavitani remenytelennek tunik.

Probalj meg hasznalni valamilyen malloc-debuggert (marmint olyat
ami azonnal megoli a progamot amint olyan teruletre ir, amit nem
allokalt/mar deallokalt. Ez kozvetlenul nem fogja megani a
problemara a megoldast, de kozelebb vihet hozza). En az
ElectricFence-t hasznalom, ami bar C-hez van kitalalva, nem lehet
tul nagy munka atportolni C++-ra. Sok sikert.

_tgz

Sziasztok !

Egy -azt hiszem klasszikus- probleman gondolkodtam:

Tobbszalu programban szeretnem hasznalni egyszerre
tobb szalon a kovetkezo fuggvenyeket:
snprintf, strncpy, atoi, es hasonlok...

Ezeknek allitolag van direkt tobbszalusagra felkeszitett
valtozata. A kerdesem az, hogyan lehet ravenni a linkert
hogy a tobbszalusag kompatibilis fuggvenyeket hasznaljam,
illetve hogyan tudom megnezni hogy most eppen melyiket hasznalja.

A kornyezet: Win32, LCC vagy GCC

- Tamas -

>Felado :  [Hungary]
>Temakor: VBA Automation ( 17 sor )
>Idopont: Thu Mar 29 15:43:07 CEST 2001 CODER #1131

>MS Access-bol szeretnek egy olyan makrot elinditani, ami
>egy Word dokumentumot modosit. Word-ben kesz a makro.
>Hogyan tudom ezt Accessbol elinditani?

Ha mar VBA-t hasznalsz, akkor miert nem rakod at a makrot Access-be?
Gyakorlatilag csak a forrast kell atemelni, beirni az elejere a set
wordApp=CreateObject("Word.Application") sort, a vegere a set wordApp=Null
sort.
Ezen felul az objektumhivatkozasoknal elebe figyelni kell arra, hogy melyik
alkalmazasra vonatkoznak, es explicite be kell irni.
Ha pl. Word-ben irtad a makrot, akkor nyugodtan hasznalhattadd a Documents()
hivatkozast, a Word elegondolta a Word.Application specifikalast, Access-be
atemelve mar a wordApp.Documents() format kell hasznalnod.

>A makrorol az objektumtallozo a kovetkezoket irja ki:
>Makro1() a Normal.NewMacros tagja
>A Normal pedig a 'C:\Program Files\Microsoft
>Office\Sablonok\Normal.dot' file.

Ha mar mindenkeppen Word-ben akarod futtatni a makrot, akkor valami hasonlot
kellene kiproblani:

set wordApp=CreateObject("Word.Application")
wordApp.Run "Normal.NewMacros.Makro1"
set wordApp=Null

Szapi

Sziasztok,

Nem tudja valaki hogyan kell kiszmolni egy adott datumra,
hogy az ev melyik hetere esik.
Itt most konkret programkodra gondolnek elsosorban.
Mivel mar lassan 1 hete kuzdok a problemaval.

Win 9x/NT alatt kell megoldani a dolgot.

Van egy fgv strftime nevu joszag, de megbolondul ha az ev utolso
hete (52.) utan vannak meg napok (pl. 2001-2002-re valo valtaskor az ev
utolso hete (52.) utan megvan egy nap (Dec31) amit 53-hetnek minosit.
A 2002 elso hetere azt mondja hogy az meg az elozo evhez tartozik
igy meg az egesz evben csuszik a hetszam. Ez ismetlodik valamilyen
csunya szabaly szerint.
Szoval nem eppen jo.

Preferalt programnyelv C++ Builder-hez (Delphi). (TDateTime-bol kell
szamolni)
De johet barmi Windows alatti, amibol meg lehet erteni mi is
tortenik valojaban. Vagy egyeb. :)))))

Koszike,
-- 
Alex.
PGP fingerprint: 8788 A44C 6257 5927 DDDC  C97C 5A43 58DB 8F15 49C8

Kedves Lista!

Koszonom mindazoknak, akik reagaltak kerdeseimre idomeres ugyben.
Sajnos lassu vagyok, nem csak ezzel foglalkozom, ill. a programon
belul is van mas irany amivel elobb haladnom kell, ezert csak most
reagalok a valaszokra. Azt hiszem, ket olyan javaslatot kaptam,
amelyek kozul valasztando ki a vegleges:

1.: QueryPerformance... Win API hivasok.

2.: Pentiumspecifikusan az RDTSC utasitas hasznalata.

3.: ROM-BIOS

1. elonye lehet, hogy valoszinuleg akkor is altalanosabb, ha a
szinfalak mogott esetleg szinten RDTSC utasitas rejtozik...

3. viszont attol tartok, megneheziti az orajellel valo
kapcsolatot...

Salom-Eirene-Pax, Udv: Tommyca