Microsoft et Java

JKB a écrit :

Le Thu, 23 Jun 2011 12:04:12 +0200,
remy <remy@fctpas.fr> écrivait :

JKB a écrit :
dans vrais vie tu prend
un kit d'eval
un ide
toolchains
un noyau ou une distribe en fonction des besoins
et du _support_

en gros
http://microcontrollershop.com/default.php?cPath=154_170_280
http://www.embeddedarm.com/software/software-arm-linux.php
http://www.eukrea.com/
...

et si ta pas de rond (microP sans MMU)
http://www.uclinux.org/

Et tu colles ton kit d'évaluation dans un produit vendu en grande
série, rigolo !

bien sur que non rigolo a poile mou ,
mais si cela fonction avec ton kit d'eval cela le fera

tien d'ailleurs un kit qui marche très mal et qui a peut être u n
problème en moins

http://www.hawkboard.org/
http://elinux.org/Hawkboard
tu a même le shéma
http://hawkboard.googlecode.com/files/Hawkboard_schematics_v1.pdf


http://groups.google.com/group/hawkboard/browse_frm/thread/c19cea97d0cbc2 81

ce type de solution n'est pas a la porté de premier venu et encore m oins
du codeur de C même si il est trés bon,l'os on n'y touche le mo ins
possible ,sauf peut etre sur les forums





remy




--
http://remyaumeunier.chez-alice.fr/

JKB a écrit :

Le Thu, 23 Jun 2011 12:04:12 +0200,
remy <remy@fctpas.fr> écrivait :

JKB a écrit :
dans vrais vie tu prend
un kit d'eval
un ide
toolchains
un noyau ou une distribe en fonction des besoins
et du _support_

en gros
http://microcontrollershop.com/default.php?cPath=154_170_280
http://www.embeddedarm.com/software/software-arm-linux.php
http://www.eukrea.com/
...

et si ta pas de rond (microP sans MMU)
http://www.uclinux.org/

Et tu colles ton kit d'évaluation dans un produit vendu en grande
série, rigolo !

devant mon ecran :-) et en plus cela merde

http://cjoint.com/11jn/AFxoHqwKHAY.htm

voila pour la vrais vie

remy
--
http://remyaumeunier.chez-alice.fr/

On 23 juin, 13:19, remy <r...@fctpas.fr> wrote:

JKB a écrit :







> Le Thu, 23 Jun 2011 12:04:12 +0200,
> remy <r...@fctpas.fr> écrivait :
>> JKB a écrit :
>> dans vrais vie tu prend
>> un kit d'eval
>> un ide
>> toolchains
>> un noyau ou une distribe en fonction des besoins
>> et du _support_

>> en gros
>>http://microcontrollershop.com/default.php?cPath=154_170_280
>>http://www.embeddedarm.com/software/software-arm-linux.php
>>http://www.eukrea.com/
>> ...

>> et si ta pas de rond (microP sans MMU)
>>http://www.uclinux.org/

>    Et tu colles ton kit d'évaluation dans un produit vendu en gra nde
>    série, rigolo !

bien sur que non rigolo a poile mou ,
mais si cela fonction avec ton kit d'eval cela le fera

tien d'ailleurs un kit qui marche très mal et qui a peut être un
problème en moins

http://www.hawkboard.org/http://elinux.org/Hawkboard
tu a même le shémahttp://hawkboard.googlecode.com/files/Hawkboard_sch ematics_v1.pdf

http://groups.google.com/group/hawkboard/browse_frm/thread/c19cea97d0...

ce type de solution n'est pas a la porté de premier venu et encore moin s
du codeur de C même si il est trés bon,l'os on n'y touche le moins
possible ,sauf peut etre sur les forums

remy

--http://remyaumeunier.chez-alice.fr/

N'importe quoi. Tu ne sais pas de quoi tu parles.
Tous tes petits joujous peuvent servir au prototypage, mais l'objectif
final dans le domaine sera de grapiller le plus possible de mémoire
lors de la mise en production en série. Et question occupation
mémoire, Java ne tient pas devant le C. Donc on peut trouver, et on
trouve encore beaucoup de softs écrits en C pour l'embarqué.

Le 22/06/2011 13:09, JKB a écrit :

Pour ta gouverne, avec une macro bien sentie, ce code est
chez moi :

CHECK(fooBar(),<...>);

où<...> contient la liste des trucs à faire pour libérer les
ressources en cas d'erreur. C'est donc vachement compliqué. CHECK
est une macro triviale et tout à fait maintenable.

Ça marche avec dlsym() ou getpriority() ?

--
Toxico Nimbus
Un peu tatillon.

totof01 a écrit :

On 23 juin, 13:19, remy <r...@fctpas.fr> wrote:

JKB a écrit :

Le Thu, 23 Jun 2011 12:04:12 +0200,
remy <r...@fctpas.fr> écrivait :

JKB a écrit :
dans vrais vie tu prend
un kit d'eval
un ide
toolchains
un noyau ou une distribe en fonction des besoins
et du _support_
en gros
http://microcontrollershop.com/default.php?cPath=154_170_280
http://www.embeddedarm.com/software/software-arm-linux.php
http://www.eukrea.com/
...
et si ta pas de rond (microP sans MMU)
http://www.uclinux.org/

Et tu colles ton kit d'évaluation dans un produit vendu en grand e
série, rigolo !

bien sur que non rigolo a poile mou ,
mais si cela fonction avec ton kit d'eval cela le fera

tien d'ailleurs un kit qui marche très mal et qui a peut être un
problème en moins

http://www.hawkboard.org/http://elinux.org/Hawkboard
tu a même le shémahttp://hawkboard.googlecode.com/files/Hawkboard_ schematics_v1.pdf

http://groups.google.com/group/hawkboard/browse_frm/thread/c19cea97d0. ..

ce type de solution n'est pas a la porté de premier venu et encore m oins
du codeur de C même si il est trés bon,l'os on n'y touche le moins
possible ,sauf peut etre sur les forums

remy

--http://remyaumeunier.chez-alice.fr/

N'importe quoi. Tu ne sais pas de quoi tu parles.
Tous tes petits joujous peuvent servir au prototypage, mais l'objectif
final dans le domaine sera de grapiller le plus possible de mémoire
lors de la mise en production en série. Et question occupation
mémoire, Java ne tient pas devant le C. Donc on peut trouver, et on
trouve encore beaucoup de softs écrits en C pour l'embarqué.

j'ai jamais dit qui y avais du java dans l'embarquer quoi que maintenant
plus rien ne m'étonne

bien sur qu'il y a du C ,mais la production ce limite a
l'applicatif ,a l'interaction entre les entrées/ sortie via les drivers
ou le réseaux eth ,port serie ,usb ,écran lcd (frame buffer) ou autre

le reste driver/noyaux et aussi en C mais ce n'est pas de la production
locale, la boite fait de l'intégration avec du support , aux pire un
driver maison d'ou l'utilise de la carte d'eval et pour la ram/DD
regarde le prix des clefs usb

le portage se sont des truc réservé au fondeur intel atmel Ti ou autr e

dans tout les cas l'on ne s' amuse pas a faire le con avec le noyaux et
les applicatifs sont jamais très gros n'y très compliqué alors le coté
je code en C je suis un dieux ... un dieux auto autoproclamé oui

remy


















--
http://remyaumeunier.chez-alice.fr/

Le 22/06/2011 15:53, Aeris Imirhil a écrit :

On 22 juin, 15:24, JKB<j...@koenigsberg.invalid> wrote:

Ça, mon grand, c'est spécifié dans le prototype et l'interface.

Gné ?
C'est quoi une interface en C ?

Comme dans tous les langages, c'est la documentation complète de
l'interaction de la fonction/méthode avec son environnement d'éxécution
(arguments, valeur de retour, exceptions, variables globales modifiées,
etc).

Je suis désolé, mais je coupe ton blabla totalement inintéressant.
Je maintiens que tu n'as pas besoin de savoir comment est fichue une
fonction à partir du moment où tu connais son interface.

C'est quoi son « interface » ? Et je la trouve où ?

cf plus haut et dans la doc.

Te rends-tu compte que ton argument est parfaitement idiote ? Si la
doc est mauvaise, il est _normal_ que le code utilisant ladite
bibliothèque soit buggué.

Pas en Java en tout cas !

Comment définis-tu un bug ? Pour moi c'est quand le fonctionnement n'est
pas conforme à celui qui est prévu dans la documentation.

Et alors ? La seule différence dans ce cas
est que le compilo Java va gueuler, mais ce n'est pas pour cela que
ton code sera bon.

Correct pas forcément. Fiable si.

Si tu ne sais pas en quoi consiste l'exception, tu ne sais pas quoi en
faire. Si une exception critique nécessite de ne plus utiliser un objet
ou une librairie sous peine de problème sévère, tu risque de l'avoir
dans le baba en C comme en Java.

Je fais comment avec ta macro pour traiter différemment l'absence de
fichier et le crash disque, et pour en avertir différemment
l'utilisateur ?

man errno

--
Toxico Nimbus

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 23/06/2011 15:25, totof01 a écrit :

Et question occupation
mémoire, Java ne tient pas devant le C. Donc on peut trouver, et on
trouve encore beaucoup de softs écrits en C pour l'embarqué.

Certains processeurs ARM embarquent une JVM *matérielle* (Jazelle), et
la place mémoire est donc largement diminuée

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOA4GnAAoJEK8zQvxDY4P9gcQH/3WKYmtUxgs5/1B4Jin1bYL9
VdT7Y9EMmFufdXgBD0GLY9C3+Qc7n5tYT1bMsVfR0ngU6awLlfU6UUG0o/yXP5XJ
BuLDQDcw1R5yH6l775dHoJX4xoFtB/DXCF+j5pe74u+LDTNNbT53xqQfQ1xn50os
I4//DlGpSWhMoEiXaz5ccdEEU+cdEvGPr3lmeNBteM6JZ+jhJeypsvXuCdQ8Gdtd
jQfTmFeaBbL+2LePXiTSF5P5lJwSK6VJ8TVjGsHEYfexJyktgLFmovnuMQJrsTMC
4zpnZRAhBbNtjHbP9E1sAt+xxwlhdo37KHJkQxOtBUUtBuFbVOuxs1/LoDBqtVE RMc
-----END PGP SIGNATURE-----

Aéris a écrit :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 23/06/2011 15:25, totof01 a écrit :

Et question occupation
mémoire, Java ne tient pas devant le C. Donc on peut trouver, et on
trouve encore beaucoup de softs écrits en C pour l'embarqué.

Certains processeurs ARM embarquent une JVM *matérielle* (Jazelle), e t
la place mémoire est donc largement diminuée

je ne connait pas cette carte
http://www.phidgets.com/products.php?category=0&product_id=1072

mais apparemment il y a un debain sur un arm
ce qui implique en theorie comme dit sur le site

Support for C, C++, Java, .NET(Mono), Python, etc.

bon maintenant l'utilité de faire du java ou du python m'échappe
bon bref un arm 9 avec les entree sortie de cette carte

http://www.phidgets.com/products.php?product_id=1018

plus une bonne couche réseaux et les driver qui vont bien
il ne manque que " l'appli métier " et l'alim

remy

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOA4GnAAoJEK8zQvxDY4P9gcQH/3WKYmtUxgs5/1B4Jin1bYL9
VdT7Y9EMmFufdXgBD0GLY9C3+Qc7n5tYT1bMsVfR0ngU6awLlfU6UUG0o/yXP5XJ
BuLDQDcw1R5yH6l775dHoJX4xoFtB/DXCF+j5pe74u+LDTNNbT53xqQfQ1xn50os
I4//DlGpSWhMoEiXaz5ccdEEU+cdEvGPr3lmeNBteM6JZ+jhJeypsvXuCdQ8Gdtd
jQfTmFeaBbL+2LePXiTSF5P5lJwSK6VJ8TVjGsHEYfexJyktgLFmovnuMQJrsTMC
4zpnZRAhBbNtjHbP9E1sAt+xxwlhdo37KHJkQxOtBUUtBuFbVOuxs1/LoDBqtVE=
=52Mc
-----END PGP SIGNATURE-----

--
http://remyaumeunier.chez-alice.fr/

Michel Talon, dans le message <itt792$oeb$2@asmodee.lpthe.jussieu.fr>, a
écrit :

Dans le même ordre d'idée il y a le typage automatique et
dynamique des variables, comme en python, et qui n'existe pas en Java,

Là, je ne suis franchement pas d'accord du tout, pour la combinaison de ces
deux raisons :

- Dans un programme correctement écrit et débuggé, une variable n'a qu'un
seul type : si quelque part on écrit « a = x + 42 », c'est que a et x sont
des nombres (entiers ou flottants), et si ailleurs on utilise a ou x comme
des pointeurs ou des tableaux, c'est qu'il y a un bug.

- Quand il y a un bug, il vaut mieux le détecter le plus tôt possible, si
possible au moment où le programme est compilé ou chargé plutôt qu'au
moment où l'endroit où se trouve l'erreur est exécuté.

Le typage statique des variables permet justement ça, et ça évite en
particulier une quantité innombrable d'erreurs idiotes, tout en posant des
inconvénients minimaux au programmeur.

Après, on peut éventuellement préférer du typage statique automatique, façon
CaML, plutôt que du typage statique explicite façon C, mais la charge de
devoir écrire « int x » la première fois est assez négligeable.

Tiens, un exemple : je suis en train de travailler sur le système de gestion
des adhérents d'une association. Dans la base de données, chaque membre peut
avoir plusieurs noms (ça sert surtout pour les femmes mariées). Pour
expédier du courrier, il faut choisir le quel de ces noms on met sur
l'enveloppe. Il y a des heuristiques, mais surtout un champ dans la
structure de données qui contient le nom. Ce champ s'appelle nom_envoi. Mais
j'avais oublié ça, et j'avais supposé qu'il s'appelait envoi tout court,
puisqu'il est de toutes façons dans la structure nom. Le langage est à
déclarations et typage dynamique : il a accepté sans broncher que j'utilise
ce champ sorti de nulle part, et du coup le mécanisme ne marchait pas. Le
bug n'a été repéré que parce que la permanente de l'association fait son
boulot très consciencieusement et a vu l'erreur de nom sur certaines des
adresses.

Si j'avais utilisé un langage avec des déclarations statiques, l'erreur
aurait été vue immédiatement. Je considère que c'est une déficience de ce
langage que de ne pas permettre une telle analyse statique du code.
Évidemment, à côté de ça, ses avantages dans d'autres domaines font que je
persiste dans mon choix du langage, mais s'il pouvait garder tous ses
avantages _et_ avoir du typage statique, ce serait infiniment mieux.

JKB a écrit :

Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil <aeris.imirhil@gmail.com> écrivait :

On 22 juin, 13:09, JKB <j...@koenigsberg.invalid> wrote:

Ton exemple est typiquement du goret-codage. D'une part, si t u ne
sais pas quel est la prototype de la fonction, tu ferais bien de ne
pas l'utiliser.

Il ne s'agit pas de connaître uniquement le prototype de la fonct ion
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?

Ça, mon grand, c'est spécifié dans le prototype et l'in terface.

tien justement en parlent de truc a la con
voila se que je trouve dans uboot

void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));

je devrait plutot dire

void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));

qui ne passe pas le compilateur

en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non


remy


--
http://remyaumeunier.chez-alice.fr/