Le Fri, 29 Jan 2010 12:58:37 +0000, JKB a écrit :Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
J'ai des Mo de codes en RPL(/2 en l'occurrence) et ça ne me pose
strictement aucun problème de lecture. Il faut simplement coller les
bons commentaires là où il faut avec le contenu de la pile si tu as
peur de ne plus t'y retrouver.
Ton code est lisible parce que tu le commente bien.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par ailleurs, on
peut dire ce qu'on veut, mais la programmation objet, c'est tout sauf
propre surtout de la façon dont c'est fait dans Java (ramasse-miette et
autres joyeusetés du même tonneaux, bidouillages infâmes avec des
connecteurs de base de données parce que tu ne sais jamais vraiment
quand tes objets vont être libérés...).
C'est un peu le propre des langages de haut-niveau. Tu es obligé de faire
confiance au langage. Tant que tu ne l'interface pas avec un autre langage, et
que tu n'essaye pas de deviner ce que fait la jvm, tout se passe (généralement)
bien.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la main
au travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et
A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa pile,
il peut modifier le A6 en question. Je ne vois pas pourquoi on ne peut
pas voir A6 et A7 en _même_ temps.
Non, tu accèdes à a7 directement avec la notation a7 ou sp, comme n'importe
quel registre d'adresse. Simplement, il y a quelques modes d'adressage qui
n'acceptent que a7.
Le Fri, 29 Jan 2010 12:58:37 +0000, JKB a écrit :
Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
J'ai des Mo de codes en RPL(/2 en l'occurrence) et ça ne me pose
strictement aucun problème de lecture. Il faut simplement coller les
bons commentaires là où il faut avec le contenu de la pile si tu as
peur de ne plus t'y retrouver.
Ton code est lisible parce que tu le commente bien.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par ailleurs, on
peut dire ce qu'on veut, mais la programmation objet, c'est tout sauf
propre surtout de la façon dont c'est fait dans Java (ramasse-miette et
autres joyeusetés du même tonneaux, bidouillages infâmes avec des
connecteurs de base de données parce que tu ne sais jamais vraiment
quand tes objets vont être libérés...).
C'est un peu le propre des langages de haut-niveau. Tu es obligé de faire
confiance au langage. Tant que tu ne l'interface pas avec un autre langage, et
que tu n'essaye pas de deviner ce que fait la jvm, tout se passe (généralement)
bien.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la main
au travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et
A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa pile,
il peut modifier le A6 en question. Je ne vois pas pourquoi on ne peut
pas voir A6 et A7 en _même_ temps.
Non, tu accèdes à a7 directement avec la notation a7 ou sp, comme n'importe
quel registre d'adresse. Simplement, il y a quelques modes d'adressage qui
n'acceptent que a7.
Le Fri, 29 Jan 2010 12:58:37 +0000, JKB a écrit :Le RPL n'est pas non plus lisible aux initiés, ce sont juste les
commentaires qui sont lisibles.
C'est parfaitement faux et au final largement plus lisible qu'un truc
comme Java.
Je ne suis pas d'accord. Pour avoir fait beaucoup de RPL, je le place
volontier dans la catégorie des langages write-only, avec Haskell.
J'ai des Mo de codes en RPL(/2 en l'occurrence) et ça ne me pose
strictement aucun problème de lecture. Il faut simplement coller les
bons commentaires là où il faut avec le contenu de la pile si tu as
peur de ne plus t'y retrouver.
Ton code est lisible parce que tu le commente bien.
Quant à Java, je le trouve plutôt lisible, pour un langage oo, malgré
les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par ailleurs, on
peut dire ce qu'on veut, mais la programmation objet, c'est tout sauf
propre surtout de la façon dont c'est fait dans Java (ramasse-miette et
autres joyeusetés du même tonneaux, bidouillages infâmes avec des
connecteurs de base de données parce que tu ne sais jamais vraiment
quand tes objets vont être libérés...).
C'est un peu le propre des langages de haut-niveau. Tu es obligé de faire
confiance au langage. Tant que tu ne l'interface pas avec un autre langage, et
que tu n'essaye pas de deviner ce que fait la jvm, tout se passe (généralement)
bien.
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la main
au travers de S. Sur le 68000, ça devient très rapidement folklorique
parce que A7 n'est jamais visible, mais le processeur échange A6 et
A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa pile,
il peut modifier le A6 en question. Je ne vois pas pourquoi on ne peut
pas voir A6 et A7 en _même_ temps.
Non, tu accèdes à a7 directement avec la notation a7 ou sp, comme n'importe
quel registre d'adresse. Simplement, il y a quelques modes d'adressage qui
n'acceptent que a7.
Ton code est lisible parce que tu le commente bien.
Je suis assez doué pour te faire un truc illisible en C voire en
Fortran 77.
C'est un peu le propre des langages de haut-niveau. Tu es obligé de
faire confiance au langage. Tant que tu ne l'interface pas avec un
autre langage, et que tu n'essaye pas de deviner ce que fait la jvm,
tout se passe (généralement) bien.
Lorsque je prends vim pour écrire du Fortran2003, je sais exactement ce
que fera mon code et à quel moment (et je ne suis pas obligé de me
taper netbeans).
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la
main au travers de S. Sur le 68000, ça devient très rapidement
folklorique parce que A7 n'est jamais visible, mais le processeur
échange A6 et A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
Non, tu accèdes à a7 directement avec la notation a7 ou sp, comme
n'importe quel registre d'adresse. Simplement, il y a quelques modes
d'adressage qui n'acceptent que a7.
Je te disais ça de mémoire. Tu es en train de me contraindre à rouvrir
ma doc. J'y cours !
...
Au temps pour moi, c'est A7 et A8, avec A8 non accessible directement
(Doc Hitachi 68000), avec la subtile distinction ISP, MSP, SSP et USP
que j'ai toujours trouvés scabreuse.
Ton code est lisible parce que tu le commente bien.
Je suis assez doué pour te faire un truc illisible en C voire en
Fortran 77.
C'est un peu le propre des langages de haut-niveau. Tu es obligé de
faire confiance au langage. Tant que tu ne l'interface pas avec un
autre langage, et que tu n'essaye pas de deviner ce que fait la jvm,
tout se passe (généralement) bien.
Lorsque je prends vim pour écrire du Fortran2003, je sais exactement ce
que fera mon code et à quel moment (et je ne suis pas obligé de me
taper netbeans).
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la
main au travers de S. Sur le 68000, ça devient très rapidement
folklorique parce que A7 n'est jamais visible, mais le processeur
échange A6 et A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
Non, tu accèdes à a7 directement avec la notation a7 ou sp, comme
n'importe quel registre d'adresse. Simplement, il y a quelques modes
d'adressage qui n'acceptent que a7.
Je te disais ça de mémoire. Tu es en train de me contraindre à rouvrir
ma doc. J'y cours !
...
Au temps pour moi, c'est A7 et A8, avec A8 non accessible directement
(Doc Hitachi 68000), avec la subtile distinction ISP, MSP, SSP et USP
que j'ai toujours trouvés scabreuse.
Ton code est lisible parce que tu le commente bien.
Je suis assez doué pour te faire un truc illisible en C voire en
Fortran 77.
C'est un peu le propre des langages de haut-niveau. Tu es obligé de
faire confiance au langage. Tant que tu ne l'interface pas avec un
autre langage, et que tu n'essaye pas de deviner ce que fait la jvm,
tout se passe (généralement) bien.
Lorsque je prends vim pour écrire du Fortran2003, je sais exactement ce
que fera mon code et à quel moment (et je ne suis pas obligé de me
taper netbeans).
Je ne vois pas ce que tu appelles le masque de pile.
Le fait que sur le 68000, tu ne peux utiliser qu'une pile à un
instant donné, la seconde étant masquée. Sur le 6809, tu as U et S.
Le processeur utilise S, tu fais ce que bon te semble avec U, et si
tu as besoin de plusieurs piles indépendantes, tu les gères à la
main au travers de S. Sur le 68000, ça devient très rapidement
folklorique parce que A7 n'est jamais visible, mais le processeur
échange A6 et A7 sur certaines instructions.
Je ne vois vraiment pas pourquoi tu dis qu'A7 n'est jamais visible.
Quant aux piles multiples, je pense qu'une primitive stackswap n'est
pas la mort à coder.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
Non, tu accèdes à a7 directement avec la notation a7 ou sp, comme
n'importe quel registre d'adresse. Simplement, il y a quelques modes
d'adressage qui n'acceptent que a7.
Je te disais ça de mémoire. Tu es en train de me contraindre à rouvrir
ma doc. J'y cours !
...
Au temps pour moi, c'est A7 et A8, avec A8 non accessible directement
(Doc Hitachi 68000), avec la subtile distinction ISP, MSP, SSP et USP
que j'ai toujours trouvés scabreuse.
> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
> malgré les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par
ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
c'est tout sauf propre
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce
que tu ne sais jamais vraiment quand tes objets vont être libérés.. .).
> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
> malgré les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par
ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
c'est tout sauf propre
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce
que tu ne sais jamais vraiment quand tes objets vont être libérés.. .).
> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
> malgré les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par
ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
c'est tout sauf propre
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce
que tu ne sais jamais vraiment quand tes objets vont être libérés.. .).
Je te disais ça de mémoire. Tu es en train de me contraindre à rouvrir
ma doc. J'y cours !
...
Au temps pour moi, c'est A7 et A8, avec A8 non accessible directement
(Doc Hitachi 68000), avec la subtile distinction ISP, MSP, SSP et USP
que j'ai toujours trouvés scabreuse.
Aucune référence à a8 chez moi dans la doc motorola/freescale. La distinction
n'est pas si subtile que ça. Les piles étant échangée automatiquement, tu
utilise toujours a7 (ou sp) de la même manière. Je ne vois rien de scabreux
là-dedans.
Je te disais ça de mémoire. Tu es en train de me contraindre à rouvrir
ma doc. J'y cours !
...
Au temps pour moi, c'est A7 et A8, avec A8 non accessible directement
(Doc Hitachi 68000), avec la subtile distinction ISP, MSP, SSP et USP
que j'ai toujours trouvés scabreuse.
Aucune référence à a8 chez moi dans la doc motorola/freescale. La distinction
n'est pas si subtile que ça. Les piles étant échangée automatiquement, tu
utilise toujours a7 (ou sp) de la même manière. Je ne vois rien de scabreux
là-dedans.
Je te disais ça de mémoire. Tu es en train de me contraindre à rouvrir
ma doc. J'y cours !
...
Au temps pour moi, c'est A7 et A8, avec A8 non accessible directement
(Doc Hitachi 68000), avec la subtile distinction ISP, MSP, SSP et USP
que j'ai toujours trouvés scabreuse.
Aucune référence à a8 chez moi dans la doc motorola/freescale. La distinction
n'est pas si subtile que ça. Les piles étant échangée automatiquement, tu
utilise toujours a7 (ou sp) de la même manière. Je ne vois rien de scabreux
là-dedans.
> Quant à Java, je le trouve plutôt lisible, pour un langage oo,
> malgré les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par
ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
c'est tout sauf propre
Par opposition à quoi ? La programmation fonctionnelle ?
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce
que tu ne sais jamais vraiment quand tes objets vont être libérés...).
?
Tes données sont libérées quand elles ne sont plus référencées.
> Quant à Java, je le trouve plutôt lisible, pour un langage oo,
> malgré les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par
ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
c'est tout sauf propre
Par opposition à quoi ? La programmation fonctionnelle ?
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce
que tu ne sais jamais vraiment quand tes objets vont être libérés...).
?
Tes données sont libérées quand elles ne sont plus référencées.
> Quant à Java, je le trouve plutôt lisible, pour un langage oo,
> malgré les try-catch qui pourrissent le code à foison.
Ouaips. C'est abscons à souhait et sans un IDE complet, il est
impossible de faire quelque chose d'un peu compliqué. Par
ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
c'est tout sauf propre
Par opposition à quoi ? La programmation fonctionnelle ?
surtout de la façon dont c'est fait dans Java
(ramasse-miette et autres joyeusetés du même tonneaux,
bidouillages infâmes avec des connecteurs de base de données parce
que tu ne sais jamais vraiment quand tes objets vont être libérés...).
?
Tes données sont libérées quand elles ne sont plus référencées.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
JKB wrote:De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
de memoire aussi, c'est plutot qu'il y avait deux a7 en // selon le
mode user ou supervisor. mais beaucoup de compilos et/ou runtime
se reservaient l'usage exclusif de a6. c'est loin, tout ça.
JKB wrote:
De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
de memoire aussi, c'est plutot qu'il y avait deux a7 en // selon le
mode user ou supervisor. mais beaucoup de compilos et/ou runtime
se reservaient l'usage exclusif de a6. c'est loin, tout ça.
JKB wrote:De mémorie (je n'ai pas ouvert ma doc d'époque), tu accèdes à A7 au
travers de A6. Et comme le processeur fait ce qu'il veut avec sa
pile, il peut modifier le A6 en question. Je ne vois pas pourquoi on
ne peut pas voir A6 et A7 en _même_ temps.
de memoire aussi, c'est plutot qu'il y avait deux a7 en // selon le
mode user ou supervisor. mais beaucoup de compilos et/ou runtime
se reservaient l'usage exclusif de a6. c'est loin, tout ça.
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Yliur ?crivait dans fr.comp.os.linux.configuration :
>
>> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
>> > malgré les try-catch qui pourrissent le code à foison.
>>
>> Ouaips. C'est abscons à souhait et sans un IDE complet, il
>> est impossible de faire quelque chose d'un peu compliqué. Par
>> ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
>> c'est tout sauf propre
>
> Par opposition à quoi ? La programmation fonctionnelle ?
Ouaips. Fonctionnelle, voire impérative.
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référenc ées.
Non. Elles sont libérées _au plus tôt_ lorsqu'elles ne sont
plus référencées (heureusement encore). Elle peuvent aussi être
libérées deux heures après dans le cas d'un GC un peu bizarre.
Lorsque tu travailles avec des structures de données hénaurmes, tu
t'en rends compte assez rapidement... :-(
JKB
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Yliur ?crivait dans fr.comp.os.linux.configuration :
>
>> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
>> > malgré les try-catch qui pourrissent le code à foison.
>>
>> Ouaips. C'est abscons à souhait et sans un IDE complet, il
>> est impossible de faire quelque chose d'un peu compliqué. Par
>> ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
>> c'est tout sauf propre
>
> Par opposition à quoi ? La programmation fonctionnelle ?
Ouaips. Fonctionnelle, voire impérative.
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référenc ées.
Non. Elles sont libérées _au plus tôt_ lorsqu'elles ne sont
plus référencées (heureusement encore). Elle peuvent aussi être
libérées deux heures après dans le cas d'un GC un peu bizarre.
Lorsque tu travailles avec des structures de données hénaurmes, tu
t'en rends compte assez rapidement... :-(
JKB
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Yliur ?crivait dans fr.comp.os.linux.configuration :
>
>> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
>> > malgré les try-catch qui pourrissent le code à foison.
>>
>> Ouaips. C'est abscons à souhait et sans un IDE complet, il
>> est impossible de faire quelque chose d'un peu compliqué. Par
>> ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
>> c'est tout sauf propre
>
> Par opposition à quoi ? La programmation fonctionnelle ?
Ouaips. Fonctionnelle, voire impérative.
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référenc ées.
Non. Elles sont libérées _au plus tôt_ lorsqu'elles ne sont
plus référencées (heureusement encore). Elle peuvent aussi être
libérées deux heures après dans le cas d'un GC un peu bizarre.
Lorsque tu travailles avec des structures de données hénaurmes, tu
t'en rends compte assez rapidement... :-(
JKB
Le Fri, 29 Jan 2010 14:23:53 +0000 (UTC)
JKB a écrit :Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Yliur ?crivait dans fr.comp.os.linux.configuration :
>
>> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
>> > malgré les try-catch qui pourrissent le code à foison.
>>
>> Ouaips. C'est abscons à souhait et sans un IDE complet, il
>> est impossible de faire quelque chose d'un peu compliqué. Par
>> ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
>> c'est tout sauf propre
>
> Par opposition à quoi ? La programmation fonctionnelle ?
Ouaips. Fonctionnelle, voire impérative.
Je ne vois pas en quoi la programmation impérative est plus propre que
la programmation objet.
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référencées.
Non. Elles sont libérées _au plus tôt_ lorsqu'elles ne sont
plus référencées (heureusement encore). Elle peuvent aussi être
libérées deux heures après dans le cas d'un GC un peu bizarre.
Lorsque tu travailles avec des structures de données hénaurmes, tu
t'en rends compte assez rapidement... :-(
JKB
Si tu limites la taille de la mémoire que peut utiliser la JVM, elle ne
déborde pas de cet espace et elle libère des références quand elle a
besoin de place.
Sinon tu peux appeler manuellement le collecteur de mémoire pour
libérer la mémoire inutile après de grosses opérations, si vraiment
tu veux récupérer ta mémoire maintenant.
Le Fri, 29 Jan 2010 14:23:53 +0000 (UTC)
JKB <knatschke@koenigsberg.fr> a écrit :
Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Yliur ?crivait dans fr.comp.os.linux.configuration :
>
>> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
>> > malgré les try-catch qui pourrissent le code à foison.
>>
>> Ouaips. C'est abscons à souhait et sans un IDE complet, il
>> est impossible de faire quelque chose d'un peu compliqué. Par
>> ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
>> c'est tout sauf propre
>
> Par opposition à quoi ? La programmation fonctionnelle ?
Ouaips. Fonctionnelle, voire impérative.
Je ne vois pas en quoi la programmation impérative est plus propre que
la programmation objet.
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référencées.
Non. Elles sont libérées _au plus tôt_ lorsqu'elles ne sont
plus référencées (heureusement encore). Elle peuvent aussi être
libérées deux heures après dans le cas d'un GC un peu bizarre.
Lorsque tu travailles avec des structures de données hénaurmes, tu
t'en rends compte assez rapidement... :-(
JKB
Si tu limites la taille de la mémoire que peut utiliser la JVM, elle ne
déborde pas de cet espace et elle libère des références quand elle a
besoin de place.
Sinon tu peux appeler manuellement le collecteur de mémoire pour
libérer la mémoire inutile après de grosses opérations, si vraiment
tu veux récupérer ta mémoire maintenant.
Le Fri, 29 Jan 2010 14:23:53 +0000 (UTC)
JKB a écrit :Le 29-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Yliur ?crivait dans fr.comp.os.linux.configuration :
>
>> > Quant à Java, je le trouve plutôt lisible, pour un langage oo,
>> > malgré les try-catch qui pourrissent le code à foison.
>>
>> Ouaips. C'est abscons à souhait et sans un IDE complet, il
>> est impossible de faire quelque chose d'un peu compliqué. Par
>> ailleurs, on peut dire ce qu'on veut, mais la programmation objet,
>> c'est tout sauf propre
>
> Par opposition à quoi ? La programmation fonctionnelle ?
Ouaips. Fonctionnelle, voire impérative.
Je ne vois pas en quoi la programmation impérative est plus propre que
la programmation objet.
>> surtout de la façon dont c'est fait dans Java
>> (ramasse-miette et autres joyeusetés du même tonneaux,
>> bidouillages infâmes avec des connecteurs de base de données parce
>> que tu ne sais jamais vraiment quand tes objets vont être
>> libérés...).
>
> ?
> Tes données sont libérées quand elles ne sont plus référencées.
Non. Elles sont libérées _au plus tôt_ lorsqu'elles ne sont
plus référencées (heureusement encore). Elle peuvent aussi être
libérées deux heures après dans le cas d'un GC un peu bizarre.
Lorsque tu travailles avec des structures de données hénaurmes, tu
t'en rends compte assez rapidement... :-(
JKB
Si tu limites la taille de la mémoire que peut utiliser la JVM, elle ne
déborde pas de cet espace et elle libère des références quand elle a
besoin de place.
Sinon tu peux appeler manuellement le collecteur de mémoire pour
libérer la mémoire inutile après de grosses opérations, si vraiment
tu veux récupérer ta mémoire maintenant.
Parce que c'est plus conforme à ce que fait le matériel.
Parce que c'est plus conforme à ce que fait le matériel.
Parce que c'est plus conforme à ce que fait le matériel.
