Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pas de bug compilo bytecode #2542

Closed
vicuna opened this issue Jul 31, 2000 · 1 comment
Closed

pas de bug compilo bytecode #2542

vicuna opened this issue Jul 31, 2000 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 31, 2000

Original bug ID: 174
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name:
Version: 3.00
OS: Win2K
Submission from: ppp244-paris6.libertysurf.fr (213.36.5.244)

Re-bonjours...
pouvez vous oublier le bug-report 173 (en incoming)...

Je viens de voir que <!ret> est renvoyee dans une construction
de tupple... c'est idiot. Et je sais pas experience de ocamlc
construit de droite a gauche (alors que ocamlopt flatten souvent
le code d'abord, donc construit de gauche a droite). Ceci
explique la difference de comportement. De toute facon ce code
est horrible ET faux.

Excusez-moi. le speed de la deadline.

PS:
1- merci pour Ocaml, le plus beau langage que je connaisse.
2- pourquoi de pas distribuer Ocaml pour M$ Win avec Cygnus.
a - j'ai entendu dire (...) que leur fork est maintenant bien
implemente et qu'il gere les threads.
b - donc enfin un debbuger Ocamlc pour Win...
c - il y a qq mois j'avais compile Ocaml avec win-gcc pour
utilise OLablGtk et OLablGL, et ca marchait pas mal du tout.
d - avec gcc le bytecode aurait de bien meilleur perf sous Win.
e - les pauvres gens contraint a Win ne seraient plus oblige d'avoir
CygWin + VisualC++ 6.0 (ce qui est mon cas... :)
f - enfin, pendant que j'y suis, pourquoi diable ne pas faire une version
GCC specifique de la VM qui utilise les "labels dynamiques" : ceci
permetrait d'avoir du bytecode threade sur toute plateforme GCC. Etant
donnee les avantages du bytecode, etant donne la facilite (hum ?) de la
chose... et etant donne le gout de Xavier Leroy pour le bytecode
threade...
(n'a-t-il pas teste cette approche pour Zinc sous 68020, GCC permet,
semble
-t-il de faire de meme en etant : un concept etrange
mais
qui a du sens :))

@++

@vicuna
Copy link
Author

vicuna commented Jul 31, 2000

Comment author: administrator

Re-bonjours...
pouvez vous oublier le bug-report 173 (en incoming)...
Je viens de voir que <!ret> est renvoyee dans une construction
de tupple... c'est idiot.

Oui, en effet, c'est un problème d'ordre d'évaluation non spécifié.

2- pourquoi de pas distribuer Ocaml pour M$ Win avec Cygnus.

Nous envisageons cela, en effet.

a - j'ai entendu dire (...) que leur fork est maintenant bien
implemente et qu'il gere les threads.

J'ai entendu la même chose; reste à vérifier que les threads marchent.

b - donc enfin un debbuger Ocamlc pour Win...
c - il y a qq mois j'avais compile Ocaml avec win-gcc pour
utilise OLablGtk et OLablGL, et ca marchait pas mal du tout.
d - avec gcc le bytecode aurait de bien meilleur perf sous Win.
e - les pauvres gens contraint a Win ne seraient plus oblige d'avoir
CygWin + VisualC++ 6.0 (ce qui est mon cas... :)

f - enfin, pendant que j'y suis, pourquoi diable ne pas faire une
version GCC specifique de la VM qui utilise les "labels
dynamiques" : ceci permetrait d'avoir du bytecode threade sur
toute plateforme GCC. Etant donnee les avantages du bytecode,
etant donne la facilite (hum ?) de la chose... et etant donne
le gout de Xavier Leroy pour le bytecode > threade...
(n'a-t-il pas teste cette approche pour Zinc sous 68020, GCC
permet, > semble -t-il de faire de meme en etant
: un concept etrange > mais qui a du sens :))

Ce que vous décrivez est implémenté en Objective Caml depuis 1995.

Cordialement,

  • Xavier Leroy

@vicuna vicuna closed this as completed Jul 31, 2000
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant