Re: [so] (no subject)

2019-03-16 Fir de Conversatie Mihai Barbulescu via so 
On Sat, 16 Mar 2019 at 10:52, Paul Olaru via so  wrote:
>
> Dacă fișierul conține un "a", vrei ca programul să citească "aa" din el cu 
> biblioteca ta?
>
> P.S: Folosește funcția reply all, nu crea o grămadă de tipicuri pe mailing 
> list.

Pe langa folosirea functiei de reply all intr-un thread cand scrii
mailuri __pune un SUBIECT in el__ si urmeaza te rog frumos indicatiile
de scriere pe lista de aici [1]. Daca nu urmati ce e la [1]
asistentilor le e imposibil sa urmareasca si sa raspunda coerent. Nu o
cerem din rautate.

[1] https://ocw.cs.pub.ro/courses/so/teme/tema-2#suport_intrebari_si_clarificari
[1'] https://ocw.cs.pub.ro/courses/so/info/lista-discutii

>
> On Sat, Mar 16, 2019, 10:40 Vaida Vlad via so  wrote:
>>
>> Totusi mi se pare ciudat cand ma uit pe teste.La testul cu fgetc,in momentul 
>> in care citesc sa zicem caracterul 'a',il citesc din fisier si dupa cand mai 
>> citesc inca un caracter,caracterul ala nu trebuie sa fie tot 'a',avand in 
>> vedere ca e in buffer?
>>
>> ___
>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Cu stimă,
Mihai Bărbulescu
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2019-03-16 Fir de Conversatie Paul Olaru via so 
Dacă fișierul conține un "a", vrei ca programul să citească "aa" din el cu
biblioteca ta?

P.S: Folosește funcția reply all, nu crea o grămadă de tipicuri pe mailing
list.

On Sat, Mar 16, 2019, 10:40 Vaida Vlad via so  wrote:

> Totusi mi se pare ciudat cand ma uit pe teste.La testul cu fgetc,in
> momentul in care citesc sa zicem caracterul 'a',il citesc din fisier si
> dupa cand mai citesc inca un caracter,caracterul ala nu trebuie sa fie tot
> 'a',avand in vedere ca e in buffer?
>
> ___
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] (no subject)

2019-03-16 Fir de Conversatie Vaida Vlad via so 
Totusi mi se pare ciudat cand ma uit pe teste.La testul cu fgetc,in momentul in 
care citesc sa zicem caracterul 'a',il citesc din fisier si dupa cand mai 
citesc inca un caracter,caracterul ala nu trebuie sa fie tot 'a',avand in 
vedere ca e in buffer?

___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2019-03-15 Fir de Conversatie Adrian Șendroiu via so 
Da, primul fgetc va citi un buffer întreg din fișier (4096 de bytes).
Următoarele apeluri vor întoarce date din buffer, fără să se mai ducă
la fișier.

On Sat, 16 Mar 2019 at 00:06, Vaida Vlad  wrote:
>
> Multumesc.Am o intrebare si legata de testul cu fgetc.Cand citesc un 
> caracter,acesta va fi pus intr-un buffer,daca mai citesc o data un 
> caracter,acesta va fi citit din buffer,nu?
> On Friday, March 15, 2019, 10:50:15 PM GMT+2, Adrian Șendroiu 
>  wrote:
>
>
> On Fri, 15 Mar 2019 at 17:31, Vaida Vlad via so  wrote:
>
> >
> > Salut.Cum pot testa fiecare test individual la tema2?
>
> Salut,
>
>
> Poți apela _test/run_test.sh, căruia îi dai parametru indexul testului:
>
> $ ./_test/run_test.sh 2
> 02) Test fgetc..passed  [02/95]
>
> Alternativ, poți rula direct executabilul asociat testului (pentru
> asta trebuie să setezi și LD_LIBRARY_PATH):
>
> $ export LD_LIBRARY_PATH=$PWD
> $ ./_test/bin/test_fgetc
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2019-03-15 Fir de Conversatie Adrian Șendroiu via so 
On Fri, 15 Mar 2019 at 17:31, Vaida Vlad via so  wrote:
>
> Salut.Cum pot testa fiecare test individual la tema2?

Salut,

Poți apela _test/run_test.sh, căruia îi dai parametru indexul testului:

$ ./_test/run_test.sh 2
02) Test fgetc..passed  [02/95]

Alternativ, poți rula direct executabilul asociat testului (pentru
asta trebuie să setezi și LD_LIBRARY_PATH):

$ export LD_LIBRARY_PATH=$PWD
$ ./_test/bin/test_fgetc
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2015-03-23 Fir de Conversatie Andrei Tuicu via so 
În data de 23 martie 2015, 09:59, Vlad Dogaru via so so@cursuri.cs.pub.ro
a scris:

 On Mon, Mar 23, 2015 at 07:36:32AM +, Sebastian ENE via so wrote:
  Salut,
 
  Am si eu o intrebare daca puteti sa ma lamuriti va rog :
 
  Pe Linux intr-un process copil aloc memorie inainte de a executa execv().
  Dupa ce am executat execv() toata memoria procesului copil se suprascrie
  (asta inclusive heap-ul in urma alocarilor cu malloc, calloc..)
  1.Apelul free() dupa execv() nu mai are sens deoarece s-a suprascris
  intreaga zona de memorie nu?

 După un execv() cu succes nu se mai execută nimic din codul de după.
 Deci dacă pui free() după nu are sens, pentru că nu se ajunge la el.

 Are sens să apelezi free dacă execv() eșuează, dar nu cred că asta
 întrebai.

  2.File descriptorii deschisi inainte de execv() se pierd, dar
  structurile aferente procesului care fac legatura cu inode-urile
  raman?

 File descriptorii nu se pierd decât dacă au flag-ul close on exec [1].
 Ceilalți rămân.  This makes sense if you think about it, poți moșteni,
 at the very least, stdin, stdout și stderr, ca să nu te trezești că ai
 executat un program redirectat într-un fișier și apoi el face exec()
 altuia care începe să scrie la consolă.

 [1]
 http://stackoverflow.com/questions/6125068/what-does-the-fd-cloexec-fcntl-flag-do

  3.Pe Windows trebuie sa dealocam memoria pentru parametrii in linie de
  comanda trimisi catre CreateProcess() din procesul parinte pentru a
  evita memory leak-uri ?

Asta nu știu.

Poti sa incerci sa rulezi cu DrMemory pe Windows sa vezi ce zice:
http://www.drmemory.org/  (free and open source).

Andrei


 Vlad
 ___
 http://ocw.cs.pub.ro/courses/so/info/lista-discutii
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2015-03-23 Fir de Conversatie Vlad Dogaru via so 
On Mon, Mar 23, 2015 at 07:36:32AM +, Sebastian ENE via so wrote:
 Salut,
 
 Am si eu o intrebare daca puteti sa ma lamuriti va rog :
 
 Pe Linux intr-un process copil aloc memorie inainte de a executa execv().
 Dupa ce am executat execv() toata memoria procesului copil se suprascrie
 (asta inclusive heap-ul in urma alocarilor cu malloc, calloc..)
 1.Apelul free() dupa execv() nu mai are sens deoarece s-a suprascris
 intreaga zona de memorie nu?

După un execv() cu succes nu se mai execută nimic din codul de după.
Deci dacă pui free() după nu are sens, pentru că nu se ajunge la el.

Are sens să apelezi free dacă execv() eșuează, dar nu cred că asta
întrebai.

 2.File descriptorii deschisi inainte de execv() se pierd, dar
 structurile aferente procesului care fac legatura cu inode-urile
 raman?

File descriptorii nu se pierd decât dacă au flag-ul close on exec [1].
Ceilalți rămân.  This makes sense if you think about it, poți moșteni,
at the very least, stdin, stdout și stderr, ca să nu te trezești că ai
executat un program redirectat într-un fișier și apoi el face exec()
altuia care începe să scrie la consolă.

[1] 
http://stackoverflow.com/questions/6125068/what-does-the-fd-cloexec-fcntl-flag-do

 3.Pe Windows trebuie sa dealocam memoria pentru parametrii in linie de
 comanda trimisi catre CreateProcess() din procesul parinte pentru a
 evita memory leak-uri ?

Asta nu știu.

Vlad
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] (no subject)

2015-03-23 Fir de Conversatie Sebastian ENE via so 
Salut,

Am si eu o intrebare daca puteti sa ma lamuriti va rog :

Pe Linux intr-un process copil aloc memorie inainte de a executa execv().
Dupa ce am executat execv() toata memoria procesului copil se suprascrie
(asta inclusive heap-ul in urma alocarilor cu malloc, calloc..)
1.Apelul free() dupa execv() nu mai are sens deoarece s-a suprascris intreaga 
zona
de memorie nu?
2.File descriptorii deschisi inainte de execv() se pierd, dar structurile 
aferente procesului
care fac legatura cu inode-urile raman?
3.Pe Windows trebuie sa dealocam memoria pentru parametrii in linie de comanda 
trimisi catre CreateProcess() din procesul parinte pentru a evita memory 
leak-uri ?

Va multumesc,
Astept raspuns Sebastian

Sent from Windows Mail

___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2015-03-23 Fir de Conversatie Adrian Stanciu via so 
2015-03-23 10:09 GMT+02:00 Andrei Tuicu via so so@cursuri.cs.pub.ro:


 În data de 23 martie 2015, 09:59, Vlad Dogaru via so so@cursuri.cs.pub.ro
 a scris:

 On Mon, Mar 23, 2015 at 07:36:32AM +, Sebastian ENE via so wrote:
  Salut,
 
  Am si eu o intrebare daca puteti sa ma lamuriti va rog :
 
  Pe Linux intr-un process copil aloc memorie inainte de a executa
  execv().
  Dupa ce am executat execv() toata memoria procesului copil se suprascrie
  (asta inclusive heap-ul in urma alocarilor cu malloc, calloc..)
  1.Apelul free() dupa execv() nu mai are sens deoarece s-a suprascris
  intreaga zona de memorie nu?

 După un execv() cu succes nu se mai execută nimic din codul de după.
 Deci dacă pui free() după nu are sens, pentru că nu se ajunge la el.

 Are sens să apelezi free dacă execv() eșuează, dar nu cred că asta
 întrebai.

  2.File descriptorii deschisi inainte de execv() se pierd, dar
  structurile aferente procesului care fac legatura cu inode-urile
  raman?

 File descriptorii nu se pierd decât dacă au flag-ul close on exec [1].
 Ceilalți rămân.  This makes sense if you think about it, poți moșteni,
 at the very least, stdin, stdout și stderr, ca să nu te trezești că ai
 executat un program redirectat într-un fișier și apoi el face exec()
 altuia care începe să scrie la consolă.

 [1]
 http://stackoverflow.com/questions/6125068/what-does-the-fd-cloexec-fcntl-flag-do

  3.Pe Windows trebuie sa dealocam memoria pentru parametrii in linie de
  comanda trimisi catre CreateProcess() din procesul parinte pentru a
  evita memory leak-uri ?

 Asta nu știu.

 Poti sa incerci sa rulezi cu DrMemory pe Windows sa vezi ce zice:
 http://www.drmemory.org/  (free and open source).


Nu este permis să ai leak-uri de memorie. Trebuie să te gândești la o
soluție să-i eliberezi.

PS: te rog să dai un titlu sugestiv la thread-urile pornite pe listă.


Adrian
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2014-03-10 Fir de Conversatie Istrate Roxana 
Atunci de ce cand copilul modifica cursorul unui fisier partajat cu
parintele si parintele vede modifcarea?


În data de 9 martie 2014, 22:49, Istrate Roxana istrateroxana2...@gmail.com
 a scris:

 Ce se intampla in cazul comenzii ls -l | grep 'c' ?
 Daca am creat un pipe pe care vreau sa-l folosesc intre parinte si
 copil,
 apoi fac un fork(), pentru a folosi pipe-ul corect, copilul (ls -l) va
 inchide STDOUT_FILENO si-l va redirecta catre inputul lui 'grep c'. Din
 cate am citit la un fork() se copiaza din parinte in copil tabela de
 file
 descriptori. Judecand dupa poza atasata, daca parintele/copilul ar
 modifica
 ce se afla la STDOUT_FILENO, i-ar fi modificata si celuilalt, iar in
 comanda anterioara ar insemna ca daca as seta outputul lui ls -l la
 grep
 'c' si outputl lui grep 'c' ar fi setat la inputul lui ceea ce nu pare
 corect. Initial se copiaza tabela, dar dupa fork() modificarile de
 tipul
 (dup, dup2) pe file descriptorii comuni nu vor fi vizibili celuilalt
 proces?

___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2014-03-10 Fir de Conversatie Matei Oprea 
Eu sincer, nu înțeleg întrebarea. Am încercat ceva, dar nu cred că e
satisfăcător. Pune și tu întrebarea _clar_ !
ᐧ

2014-03-10 22:01 GMT+02:00 Istrate Roxana istrateroxana2...@gmail.com:
 Atunci de ce cand copilul modifica cursorul unui fisier partajat cu
 parintele si parintele vede modifcarea?


 În data de 9 martie 2014, 22:49, Istrate Roxana
 istrateroxana2...@gmail.com a scris:

 Ce se intampla in cazul comenzii ls -l | grep 'c' ?
 Daca am creat un pipe pe care vreau sa-l folosesc intre parinte si
 copil,
 apoi fac un fork(), pentru a folosi pipe-ul corect, copilul (ls -l) va
 inchide STDOUT_FILENO si-l va redirecta catre inputul lui 'grep c'.
 Din
 cate am citit la un fork() se copiaza din parinte in copil tabela de
 file
 descriptori. Judecand dupa poza atasata, daca parintele/copilul ar
 modifica
 ce se afla la STDOUT_FILENO, i-ar fi modificata si celuilalt, iar in
 comanda anterioara ar insemna ca daca as seta outputul lui ls -l la
 grep
 'c' si outputl lui grep 'c' ar fi setat la inputul lui ceea ce nu pare
 corect. Initial se copiaza tabela, dar dupa fork() modificarile de
 tipul
 (dup, dup2) pe file descriptorii comuni nu vor fi vizibili celuilalt
 proces?



 ___
 http://ocw.cs.pub.ro/courses/so/info/lista-discutii



-- 
Oprea Matei
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2014-03-10 Fir de Conversatie Veronica Velciu 
 2014-03-10 22:01 GMT+02:00 Istrate Roxana istrateroxana2...@gmail.com:
 Atunci de ce cand copilul modifica cursorul unui fisier partajat cu
 parintele si parintele vede modifcarea?


Din cate am inteles eu, la apelul unui fork() se copiaza tabela de
file descriptori (adica procesul copil va avea propria tabela), dar
file descriptorii din cele doua tabele pointeaza catre aceleasi
intrari din tabela de fisiere deschise a sistemului (system-wide table
of open files). Intrarile din tabela de fisiere deschise contin si
offset-ul in cadrul fisierului, asa ca, atat parintele, cat si
copilul, vor avea acces la pozitia cursorului.
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] (no subject)

2014-03-09 Fir de Conversatie Istrate Roxana 
Ce se intampla in cazul comenzii ls -l | grep 'c' ?
Daca am creat un pipe pe care vreau sa-l folosesc intre parinte si
copil,
apoi fac un fork(), pentru a folosi pipe-ul corect, copilul (ls -l) va
inchide STDOUT_FILENO si-l va redirecta catre inputul lui 'grep c'. Din
cate am citit la un fork() se copiaza din parinte in copil tabela de
file
descriptori. Judecand dupa poza atasata, daca parintele/copilul ar
modifica
ce se afla la STDOUT_FILENO, i-ar fi modificata si celuilalt, iar in
comanda anterioara ar insemna ca daca as seta outputul lui ls -l la grep
'c' si outputl lui grep 'c' ar fi setat la inputul lui ceea ce nu pare
corect. Initial se copiaza tabela, dar dupa fork() modificarile de tipul
(dup, dup2) pe file descriptorii comuni nu vor fi vizibili celuilalt
proces?
attachment: image.png___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

Re: [so] (no subject)

2014-03-09 Fir de Conversatie Razvan Crainea 
2014-03-09 22:49 GMT+02:00 Istrate Roxana istrateroxana2...@gmail.com:

 Ce se intampla in cazul comenzii ls -l | grep 'c' ?
 Daca am creat un pipe pe care vreau sa-l folosesc intre parinte si
 copil,
 apoi fac un fork(), pentru a folosi pipe-ul corect, copilul (ls -l) va
 inchide STDOUT_FILENO si-l va redirecta catre inputul lui 'grep c'. Din
 cate am citit la un fork() se copiaza din parinte in copil tabela de
 file
 descriptori. Judecand dupa poza atasata, daca parintele/copilul ar
 modifica
 ce se afla la STDOUT_FILENO, i-ar fi modificata si celuilalt, iar in
 comanda anterioara ar insemna ca daca as seta outputul lui ls -l la
 grep
 'c' si outputl lui grep 'c' ar fi setat la inputul lui ceea ce nu pare
 corect. Initial se copiaza tabela, dar dupa fork() modificarile de
 tipul
 (dup, dup2) pe file descriptorii comuni nu vor fi vizibili celuilalt
 proces?


Bună, Roxana!

Atenție, tabela de file descriptori se copiază, nu se folosește aceeași
tabelă. După apelul fork() procesul copil va avea propria copie a tabelei
de file descriptori, iar orice modificare (fie a părintelui sau a
copilului) este făcută în tabela proprie și nu este vizibilă celuilalt
proces.

PS: te rog să specifici un subiect threadului[1]
[1] http://ocw.cs.pub.ro/courses/so/info/lista-discutii#subjecte_sugestive

Numai bine,
-- 
Răzvan Crainea
___
http://ocw.cs.pub.ro/courses/so/info/lista-discutii

[so] (no subject)

2012-03-22 Fir de Conversatie george george 
Salut,

Am o problema cu testul 5 de pe linux. Comanda din fisier care imi creeaza 
probleme este pwd  pwd.txt.
Atunci cand testez manual fisierul merge ok. Pe checkerul local imi da fail. 
S-a mai intalnit cineva cu problema asta?
___
http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii

Re: [so] (no subject)

2012-03-22 Fir de Conversatie Razvan Crainea 
2012/3/22 george george ex_lemist2...@yahoo.com:
 Salut,

 Am o problema cu testul 5 de pe linux. Comanda din fisier care imi creeaza
 probleme este pwd  pwd.txt.
 Atunci cand testez manual fisierul merge ok. Pe checkerul local imi da fail.
 S-a mai intalnit cineva cu problema asta?

Salut, George!

Ești sigur că atunci când schimbi directorul, comanda pwd afișează ce
trebuie? Încearcă să setezi în fișierul de test _test/run_test.sh
variabila DO_CLEANUP=no și să verifci outputul programului tău.

-- 
Răzvan Crainea
___
http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii

[so] (no subject)

2010-12-14 Fir de Conversatie f.br...@yahoo.com 
http://drrsistemas.com.ar/clickhere.php


  ___
http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii