Traduction professionnelle Anglais Français
Traductrice professionnelle Anglais Frangais Bonjour, Je viens vers vous car dans le cadre de mon activiti: Traduction Anglais - Frangais - Anglais, j'aimerais collaborer avec vous et vous proposer mes services. TRADUCTION Sites Internet CV norme anglophone Menus, Plaquettes commerciales Oeuvres d'art Ouvrages techniques, iconomiques, financiers. Correspondance d'affaires, courriers. Travaux fin d'itudes Projets PRESENTATION Issue d'une famille de Professeurs d'ANGLAIS Britanniques, itant moi-mjme Enseignante en ANGLAIS, parfaitement bilingue, ayant la double nationaliti Frangaise et Britannique, je vous propose mes services de TRADUCTEUR: ANGLAIS-FRANGAIS-ANGLAIS. Grbce ` mon expirience acquise ces dernihres annies, je peux traiter un large spectre de domaines. Je suis iquipie de dictionnaires de spicialitis ainsi que de plusieurs encyclopidies et outils informatiques. Prihre de m'envoyer vos travaux en fichier Word de prifirence, mais je suis en mesure de traiter la plupart des formats de fichiers et aussi les travaux scannis, fax, envois par la poste. Dans le souci de rendre ` mes clients un travail de qualiti, les traductions sont contrtlies grbce ` une relecture effectuie par un autre Traducteur confirmi. Tarifs moyens TTC: 0,09 euros / mot source ou 20 euros p.A4 Tarifs sur devis pour certains travaux selon leur complexiti et volume. Tarif Cours et Interpritariat sur devis Statut auto entrepreneur TVA non applicable, art.293-B du CGI *Respect de la confidentialiti* N'hisitez pas ` m'icrire pour plus d'informations Cordialement Emma GEE email: emmypr...@hotmail.fr Fax : 09 56 11 25 65 J'ai eu votre adresse email en consultant le site web des pages jaunes ou bien directement sur votre site internet, si vous voulez que je la supprime de la liste de mes contacts, veuillez s.v.p ripondre ` ce message en mettant en objet : supprimer . Merci.
AMD cpuid feature flags for i386
The following lets i386 print out AMD specific feature flags
(ie NXE, LONG) similiar to what we already do on amd64.
The Cyrix 3DNOW flag is removed as it should show up
in the AMD specific flags in addition to the Intel ones.
Index: i386/locore.s
===
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.140
diff -u -p -r1.140 locore.s
--- i386/locore.s 12 Oct 2011 18:30:09 - 1.140
+++ i386/locore.s 28 Oct 2011 09:42:38 -
@@ -156,6 +156,7 @@
.globl _C_LABEL(cpuid_level)
.globl _C_LABEL(cpu_miscinfo)
.globl _C_LABEL(cpu_feature), _C_LABEL(cpu_ecxfeature)
+ .globl _C_LABEL(cpu_amdfeature)
.globl _C_LABEL(cpu_cache_eax), _C_LABEL(cpu_cache_ebx)
.globl _C_LABEL(cpu_cache_ecx), _C_LABEL(cpu_cache_edx)
.globl _C_LABEL(cold), _C_LABEL(cnvmem), _C_LABEL(extmem)
@@ -193,6 +194,7 @@ _C_LABEL(cpu): .long 0 # are we 386, 38
_C_LABEL(cpu_id): .long 0 # saved from 'cpuid' instruction
_C_LABEL(cpu_miscinfo):.long 0 # misc info (apic/brand id)
from 'cpuid'
_C_LABEL(cpu_feature): .long 0 # feature flags from 'cpuid' instruction
+_C_LABEL(cpu_amdfeature): .long0 # AMD feature flags from 'cpuid'
_C_LABEL(cpu_ecxfeature):.long 0 # extended feature flags from 'cpuid'
_C_LABEL(cpuid_level): .long -1 # max. lvl accepted by 'cpuid' insn
_C_LABEL(cpu_cache_eax):.long 0
@@ -407,6 +409,9 @@ try586: /* Use the `cpuid' instruction.
cpuid
cmpl$0x8000,%eax
jbe 2f
+ movl$0x8001,%eax
+ cpuid
+ movl%edx,RELOC(_C_LABEL(cpu_amdfeature))
movl$0x8002,%eax
cpuid
movl%eax,RELOC(_C_LABEL(cpu_brandstr))
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.505
diff -u -p -r1.505 machdep.c
--- i386/machdep.c 5 Jul 2011 04:48:01 - 1.505
+++ i386/machdep.c 28 Oct 2011 09:42:40 -
@@ -983,8 +983,17 @@ const struct cpu_cpuid_feature i386_cpui
{ CPUID_SS, SS },
{ CPUID_HTT,HTT },
{ CPUID_TM, TM },
- { CPUID_SBF,SBF },
- { CPUID_3DNOW, 3DNOW },
+ { CPUID_SBF,SBF }
+};
+
+const struct cpu_cpuid_feature i386_cpuid_amdfeatures[] = {
+ { CPUID_MPC,MPC },
+ { CPUID_NXE,NXE },
+ { CPUID_MMXX, MMXX },
+ { CPUID_FFXSR, FFXSR },
+ { CPUID_LONG, LONG },
+ { CPUID_3DNOW2, 3DNOW2 },
+ { CPUID_3DNOW, 3DNOW }
};
const struct cpu_cpuid_feature i386_cpuid_ecxfeatures[] = {
@@ -1826,6 +1835,14 @@ identifycpu(struct cpu_info *ci)
i386_cpuid_features[i].feature_bit) {
printf(%s%s, (numbits == 0 ? :
,),
i386_cpuid_features[i].feature_name);
+ numbits++;
+ }
+ }
+ for (i = 0; i nitems(i386_cpuid_amdfeatures); i++) {
+ if (cpu_amdfeature
+ i386_cpuid_amdfeatures[i].feature_bit) {
+ printf(%s%s, (numbits == 0 ? :
,),
+
i386_cpuid_amdfeatures[i].feature_name);
numbits++;
}
}
Index: include/cpu.h
===
RCS file: /cvs/src/sys/arch/i386/include/cpu.h,v
retrieving revision 1.120
diff -u -p -r1.120 cpu.h
--- include/cpu.h 23 May 2011 09:54:20 - 1.120
+++ include/cpu.h 28 Oct 2011 09:42:41 -
@@ -311,6 +311,7 @@ extern char cpu_brandstr[];
extern int cpuid_level;
extern int cpu_miscinfo;
extern int cpu_feature;
+extern int cpu_amdfeature;
extern int cpu_ecxfeature;
extern int cpu_cache_eax;
extern int cpu_cache_ebx;
Index: include/specialreg.h
===
RCS file: /cvs/src/sys/arch/i386/include/specialreg.h,v
retrieving revision 1.39
diff -u -p -r1.39 specialreg.h
--- include/specialreg.h29 Apr 2010 17:00:48 - 1.39
+++ include/specialreg.h28 Oct 2011 09:42:42 -
@@ -122,15 +122,6 @@
#define CPUID_B30 0x4000 /* reserved */
#define CPUID_SBF 0x8000 /* signal break on FERR */
-/*
- * Note: The 3DNOW flag does not really belong in this feature set since it is
- * returned by the cpuid instruction when called with 0x8001 in eax rather
- * than 0x0001, but cyrix3_cpu_setup() moves it to a reserved bit of the
- * feature set for simplicity
- */
-#define CPUID_3DNOW0x4000 /* has
October 13 2011 NAT update
You guys might want to add a note to current.html that from October 13 2011, the NAT updates have made it impossible to not use an address family in a nat-to statement. The following statement fails now: match out on egress from ($int_if:network) nat-to (egress) Gives the error: /etc/pf.conf:74: af-to is not supported on match rules /etc/pf.conf:74: skipping rule due to errors Changing it to: match out on egress inet from ($int_if:network) nat-to (egress) Fixes it. I wasn't sure how many people explicitly use the address family in their nat-to lines, but this one caught me out when I updated to a newer snapshot earlier this month. Tom
Re: AMD cpuid feature flags for i386
Date: Fri, 28 Oct 2011 20:54:48 +1100
From: Jonathan Gray j...@goblin.cx
The following lets i386 print out AMD specific feature flags
(ie NXE, LONG) similiar to what we already do on amd64.
The Cyrix 3DNOW flag is removed as it should show up
in the AMD specific flags in addition to the Intel ones.
I like thise, but:
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.505
diff -u -p -r1.505 machdep.c
--- i386/machdep.c5 Jul 2011 04:48:01 - 1.505
+++ i386/machdep.c28 Oct 2011 09:42:40 -
@@ -983,8 +983,17 @@ const struct cpu_cpuid_feature i386_cpui
{ CPUID_SS, SS },
{ CPUID_HTT,HTT },
{ CPUID_TM, TM },
- { CPUID_SBF,SBF },
- { CPUID_3DNOW, 3DNOW },
+ { CPUID_SBF,SBF }
+};
+
+const struct cpu_cpuid_feature i386_cpuid_amdfeatures[] = {
The amd64 code calls this cpu_ecpuid_features. Perhaps it is better
to use the same name or at least a similar name? Also, these seem to
be relevant to Intel CPUs as well isn't it?
+ { CPUID_MPC,MPC },
+ { CPUID_NXE,NXE },
+ { CPUID_MMXX, MMXX },
+ { CPUID_FFXSR, FFXSR },
+ { CPUID_LONG, LONG },
+ { CPUID_3DNOW2, 3DNOW2 },
+ { CPUID_3DNOW, 3DNOW }
};
Re: October 13 2011 NAT update
On Fri, Oct 28, 2011 at 12:09 PM, Tom Murphy open...@pertho.net wrote: You guys might want to add a note to current.html that from October 13 2011, the NAT updates have made it impossible to not use an address family in a nat-to statement. The following statement fails now: match out on egress from ($int_if:network) nat-to (egress) Gives the error: /etc/pf.conf:74: af-to is not supported on match rules /etc/pf.conf:74: skipping rule due to errors Changing it to: match out on egress inet from ($int_if:network) nat-to (egress) Fixes it. I wasn't sure how many people explicitly use the address family in their nat-to lines, but this one caught me out when I updated to a newer snapshot earlier this month. Tom yes, i have a proper fix for that. need to test it though.
Re: AMD cpuid feature flags for i386
On Fri, Oct 28, 2011 at 03:01:42PM +0200, Mark Kettenis wrote:
Date: Fri, 28 Oct 2011 20:54:48 +1100
From: Jonathan Gray j...@goblin.cx
The following lets i386 print out AMD specific feature flags
(ie NXE, LONG) similiar to what we already do on amd64.
The Cyrix 3DNOW flag is removed as it should show up
in the AMD specific flags in addition to the Intel ones.
I like thise, but:
The amd64 code calls this cpu_ecpuid_features. Perhaps it is better
to use the same name or at least a similar name? Also, these seem to
be relevant to Intel CPUs as well isn't it?
The comments refer to ecx as extended as well, and I
am under the perhaps mistaken impression that AMD defines
these cpuid values, especially as many values duplicate those
found in the default results. But as the intel and amd documents
both refer to them as extended how about the following, now
with some 8000_0001 ecx flags as well.
Index: i386/locore.s
===
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.140
diff -u -p -r1.140 locore.s
--- i386/locore.s 12 Oct 2011 18:30:09 - 1.140
+++ i386/locore.s 28 Oct 2011 13:51:36 -
@@ -156,6 +156,7 @@
.globl _C_LABEL(cpuid_level)
.globl _C_LABEL(cpu_miscinfo)
.globl _C_LABEL(cpu_feature), _C_LABEL(cpu_ecxfeature)
+ .globl _C_LABEL(ecpu_feature), _C_LABEL(ecpu_ecxfeature)
.globl _C_LABEL(cpu_cache_eax), _C_LABEL(cpu_cache_ebx)
.globl _C_LABEL(cpu_cache_ecx), _C_LABEL(cpu_cache_edx)
.globl _C_LABEL(cold), _C_LABEL(cnvmem), _C_LABEL(extmem)
@@ -193,7 +194,9 @@ _C_LABEL(cpu): .long 0 # are we 386, 38
_C_LABEL(cpu_id): .long 0 # saved from 'cpuid' instruction
_C_LABEL(cpu_miscinfo):.long 0 # misc info (apic/brand id)
from 'cpuid'
_C_LABEL(cpu_feature): .long 0 # feature flags from 'cpuid' instruction
-_C_LABEL(cpu_ecxfeature):.long 0 # extended feature flags from 'cpuid'
+_C_LABEL(ecpu_feature): .long 0 # extended feature flags from 'cpuid'
+_C_LABEL(cpu_ecxfeature):.long 0 # ecx feature flags from 'cpuid'
+_C_LABEL(ecpu_ecxfeature): .long 0 # extended ecx feature flags
_C_LABEL(cpuid_level): .long -1 # max. lvl accepted by 'cpuid' insn
_C_LABEL(cpu_cache_eax):.long 0
_C_LABEL(cpu_cache_ebx):.long 0
@@ -407,6 +410,10 @@ try586:/* Use the `cpuid' instruction.
cpuid
cmpl$0x8000,%eax
jbe 2f
+ movl$0x8001,%eax
+ cpuid
+ movl%edx,RELOC(_C_LABEL(ecpu_feature))
+ movl%ecx,RELOC(_C_LABEL(ecpu_ecxfeature))
movl$0x8002,%eax
cpuid
movl%eax,RELOC(_C_LABEL(cpu_brandstr))
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.505
diff -u -p -r1.505 machdep.c
--- i386/machdep.c 5 Jul 2011 04:48:01 - 1.505
+++ i386/machdep.c 28 Oct 2011 13:51:38 -
@@ -983,8 +983,17 @@ const struct cpu_cpuid_feature i386_cpui
{ CPUID_SS, SS },
{ CPUID_HTT,HTT },
{ CPUID_TM, TM },
- { CPUID_SBF,SBF },
- { CPUID_3DNOW, 3DNOW },
+ { CPUID_SBF,SBF }
+};
+
+const struct cpu_cpuid_feature i386_ecpuid_features[] = {
+ { CPUID_MPC,MPC },
+ { CPUID_NXE,NXE },
+ { CPUID_MMXX, MMXX },
+ { CPUID_FFXSR, FFXSR },
+ { CPUID_LONG, LONG },
+ { CPUID_3DNOW2, 3DNOW2 },
+ { CPUID_3DNOW, 3DNOW }
};
const struct cpu_cpuid_feature i386_cpuid_ecxfeatures[] = {
@@ -1014,6 +1023,16 @@ const struct cpu_cpuid_feature i386_cpui
{ CPUIDECX_AVX, AVX },
};
+const struct cpu_cpuid_feature i386_ecpuid_ecxfeatures[] = {
+ { CPUIDECX_LAHF,LAHF },
+ { CPUIDECX_SVM, SVM },
+ { CPUIDECX_ABM, ABM },
+ { CPUIDECX_SSE4A, SSE4A },
+ { CPUIDECX_XOP, XOP },
+ { CPUIDECX_WDT, WDT },
+ { CPUIDECX_FMA4,FMA4 }
+};
+
void
winchip_cpu_setup(struct cpu_info *ci)
{
@@ -1829,6 +1848,14 @@ identifycpu(struct cpu_info *ci)
numbits++;
}
}
+ for (i = 0; i nitems(i386_ecpuid_features); i++) {
+ if (ecpu_feature
+ i386_ecpuid_features[i].feature_bit) {
+ printf(%s%s, (numbits == 0 ? :
,),
+
i386_ecpuid_features[i].feature_name);
+ numbits++;
+ }
+ }
max = sizeof(i386_cpuid_ecxfeatures)
/ sizeof(i386_cpuid_ecxfeatures[0]);
İyi Bayramlar Diler Reklam Projesi
Say}n Yetkili; Kurban Bayram}nda firmalar}m}z igin haz}rlad}p}m}z ]Y] BAYRAMLAR D]LER proje detaylar} a~ap}daki gibidir. 06-07-08 Kas}m tarihlerinde her kanalda g|nde 7 defa ~eklinde yay}nlanacakt}r. 1.SKYTURK 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 2.KANALTURK 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 3.KANAL24 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 4.SAMANYOLU HABER 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 5.TGRT HABER 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 6.ULKE TV 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 7.BUGUN TV 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) 8.A HABER 21 ADET 4SN.L]K KU^AK REKLAM(84sn.) Toplam Spot: 168 adet ku~ak reklam. Toplam S|re: 672sn. SADECE ve SADECE 3.350 TL+KDV Deperlendirmelerinizi bekler, ]yi gal}~malar dilerim. Sayg}lar}mla... ALTERNAT]F MEDYA Hasan KARA Composition Artist T:0216 459 0 444 F:0216 459 0 555 ha...@alternatifmedya.tv alternatifmedya...@gmail.com Not: Mail almak istemiyorsan}z bu maili 'listenizden g}kmak istiyorum' diye cevaplaman}z yeterlidir.
use M_PROTO1 in bridge output too
M_PROTO1 is used by if_bridge on the input path. On the output path it's
used now only by if_bridge for if_gif. I think we can use it generically
to mark packets as processed by bridge in the output path.
The diff simplifies things and avoids mtag checking and allocation so is
more efficient too.
The old code checks if a packet has passed the _same_ bridge already, but
as an interface can only be a member of one bridge I think the flag is
sufficient.
It looks like the only other user of M_PROTO1 is netbt/hci_link.c, but
that can be fixed if the diff is acceptable otherwise.
Tested lightly in a bridge/gif setup, but could use some more testing.
(especially with ipsec in the mix too)
Index: if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.193
diff -u -p -r1.193 if_bridge.c
--- if_bridge.c 4 Jul 2011 06:54:49 - 1.193
+++ if_bridge.c 28 Oct 2011 17:55:04 -
@@ -2813,9 +2813,8 @@ bridge_ifenqueue(struct bridge_softc *sc
#if NGIF 0
/* Packet needs etherip encapsulation. */
if (ifp-if_type == IFT_GIF) {
- m-m_flags |= M_PROTO1;
-
/* Count packets input into the gif from outside */
+ /* XXX do this in if_gif? */
ifp-if_ipackets++;
ifp-if_ibytes += m-m_pkthdr.len;
}
@@ -2844,6 +2843,7 @@ bridge_ifenqueue(struct bridge_softc *sc
}
#endif
len = m-m_pkthdr.len;
+ m-m_flags |= M_PROTO1;
mflags = m-m_flags;
IFQ_ENQUEUE(ifp-if_snd, m, NULL, error);
if (error) {
Index: if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.151
diff -u -p -r1.151 if_ethersubr.c
--- if_ethersubr.c 9 Jul 2011 00:47:18 - 1.151
+++ if_ethersubr.c 28 Oct 2011 17:55:04 -
@@ -382,40 +382,8 @@ ether_output(ifp0, m0, dst, rt0)
* Interfaces that are bridge members need special handling
* for output.
*/
- if (ifp-if_bridge) {
- struct m_tag *mtag;
-
- /*
-* Check if this packet has already been sent out through
-* this bridge, in which case we simply send it out
-* without further bridge processing.
-*/
- for (mtag = m_tag_find(m, PACKET_TAG_BRIDGE, NULL); mtag;
- mtag = m_tag_find(m, PACKET_TAG_BRIDGE, mtag)) {
-#ifdef DEBUG
- /* Check that the information is there */
- if (mtag-m_tag_len != sizeof(caddr_t)) {
- error = EINVAL;
- goto bad;
- }
-#endif
- if (!bcmp(ifp-if_bridge, mtag + 1, sizeof(caddr_t)))
- break;
- }
- if (mtag == NULL) {
- /* Attach a tag so we can detect loops */
- mtag = m_tag_get(PACKET_TAG_BRIDGE, sizeof(caddr_t),
- M_NOWAIT);
- if (mtag == NULL) {
- error = ENOBUFS;
- goto bad;
- }
- bcopy(ifp-if_bridge, mtag + 1, sizeof(caddr_t));
- m_tag_prepend(m, mtag);
- error = bridge_output(ifp, m, NULL, NULL);
- return (error);
- }
- }
+ if (ifp-if_bridge !(m-m_flags M_PROTO1))
+ return (bridge_output(ifp, m, NULL, NULL));
#endif
mflags = m-m_flags;
len = m-m_pkthdr.len;
PATCH: /usr/bin/ftp: Remove fragment/anchor identifier before making request
Hi,
I was trying to use the 'ftp' program to retrieve the following URL:
https://pypi.python.org/packages/source/p/pip/pip-1.0.2.tar.gz#md5=47ec6ff3f6d962696fe08d4c8264ad49
Which fails because it considers the fragment as part of the path, and
so the server returns 404. These type of links are quite common these
days and so it would be nice if 'ftp' would handle them.
This is my first patch to OpenBSD, so please let me know if there is
anyhthing else I can do to get this feature implemented. The patch is
very simple, and I think, correct, as '#' is an unsafe character, and
must always be URL-encoded if it is to appear literally in a URL and
not be interpreted as the start of a fragment identifier.
Regards,
Eric P. Mangold
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.103
diff -u -r1.103 fetch.c
--- fetch.c 25 Aug 2010 20:32:37 - 1.103
+++ fetch.c 29 Oct 2011 03:34:02 -
@@ -205,6 +205,11 @@
if (newline == NULL)
errx(1, Can't allocate memory to parse URL);
if (strncasecmp(newline, HTTP_URL, sizeof(HTTP_URL) - 1) == 0) {
+/* Remove any trailing fragment identifier from the HTTP URL.
+ * Fragments (HTTP anchors) are identified by a hash char
('#'),
+ * as per RFC 3986. */
+newline = strsep(newline, #);
+
host = newline + sizeof(HTTP_URL) - 1;
#ifndef SMALL
scheme = HTTP_URL;
@@ -221,6 +226,11 @@
#ifndef SMALL
scheme = FILE_URL;
} else if (strncasecmp(newline, HTTPS_URL, sizeof(HTTPS_URL) - 1) == 0)
{
+/* Remove any trailing fragment identifier from the HTTPS URL.
+ * Fragments (HTTP anchors) are identified by a hash char
('#'),
+ * as per RFC 3986. */
+newline = strsep(newline, #);
+
host = newline + sizeof(HTTPS_URL) - 1;
ishttpsurl = 1;
scheme = HTTPS_URL;
