1. |
VBA Automation - koszonet (mind) |
21 sor |
(cikkei) |
2. |
Re: segfault a malloc.c-ben (mind) |
19 sor |
(cikkei) |
3. |
InterBase (mind) |
31 sor |
(cikkei) |
4. |
Re: *** HIX CODER *** #1131 (mind) |
46 sor |
(cikkei) |
5. |
Re: *** HIX CODER *** #1131 (mind) |
63 sor |
(cikkei) |
6. |
Re: segfault a malloc.c-ben (mind) |
16 sor |
(cikkei) |
7. |
Tobbszalusag (mind) |
16 sor |
(cikkei) |
8. |
Re:VBA Automation (mind) |
31 sor |
(cikkei) |
9. |
A het szama (mind) |
26 sor |
(cikkei) |
10. |
Re: idomeres (mind) |
21 sor |
(cikkei) |
|
+ - | VBA Automation - koszonet (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Re: segfault a malloc.c-ben (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | InterBase (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Re: *** HIX CODER *** #1131 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Re: *** HIX CODER *** #1131 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Re: segfault a malloc.c-ben (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Tobbszalusag (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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 -
|
+ - | Re:VBA Automation (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>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
|
+ - | A het szama (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Re: idomeres (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
|