search for: dsit

I need someone to help me: which version of Zimbra I can install on CentOS 6.2 with 32bits? I tried to do it with ver. 7.2 64 bits and I couldn't... -- Lic. Alexander Leyva Fonseca Especialista en Ciencias Inform?ticas DSIT (Centro de Investigaciones Sider?rgicas) ACINOX-Nicaro Jabber: aleyva at mail.dsit.cu Telfs: 51-6396, 51-6827, 51-6849, 51-6580 Ext. 101 Fax: 51-7276 "Libertad es el derecho que todo hombre tiene a ser honrado, y a pensar y a hablar sin hipocres?a"

...ction with my provider and at that time I don know how to configure it. I send and receive mails im my lan but I cant do it downloading from my provider. Could someone help me? -- Lic. Alexander Leyva Fonseca Especialista en Ciencias Inform?ticas Desarrollo de Servicios e Insumos Tecnol?gicos (DSIT) ACINOX-Nicaro Tel?f.(0124) 516396, 516827, 516849 Ext. 101

Hello, here is the second release of kpartx : the shameless perversion of util-linux's partx. As before it : 1) compiles against klibc 2) read partitions table like partx 3) drives the device mapper to present the partitions bdevs Find it at http://dsit.free.fr/kpartx-0.0.2.tar.bz2 This release adds a interesting functionality : it can now read partitions tables from regular files, automagically assign a loop device (like the mount cmd), and map devmaps from here. Example : here, /tmp/test is a dump of an USB key root@zezette../kpartx-0.0.2$ ....

>-----Original Message----- >From: Robin Getz [mailto:rgetz@blackfin.uclinux.org] >Sent: Tuesday, June 19, 2007 9:35 PM > > >On Tue 19 Jun 2007 13:00, Michael Shatz pondered: >> Robin Getz wrote: >> >I never met any hardware that gcc could not run code on. toolchains have >> >nothing do with embedded OSes. >> >> That's true. Add some

From: Jim Crichton [mailto:jim.crichton@comcast.net] Sent: Tuesday, June 19, 2007 10:47 PM > >For TI DSPs, I used a private memory array rather than the C stack, and a >debug patch in stack_alloc.h to measure the scratch usage: > >#if 1 >extern char *spxGlobalScratchFree; >#define ALLOC(var, size, type) (var = PUSH(stack, size, type),

> >Actually, you're the first I know using the VisualDSP++ toolchain :-) > I guess that's because speex has pretty big memory footprint. So developers that integrate speex tend to have plenty of RAM and once one has plenty of RAM he could install biggish OS. And between biggish OSes for Blackfin the most popular choice is uCLinux. And ucLinux works best with gnu tools. Something

Hi Jean-Marc I'm trying to integrate your speex codec on our custom Blackfin board. The board is not uCLinux compatible and there is no chance that it will ever be. I am using ADI-supplied VisualDSP++ IDE and corresponding toolchain. As long as I am compiling "C"-only version of the library everything is fine. VisualDSP++ produces working library. There is only one not so minor

-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, June 14, 2007 11:17 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain Michael Shatz a ?crit : >>> Actually, you're the first I know using the VisualDSP++ toolchain >>> :-) >> >> I guess

-----Original Message----- From: Robin Getz [mailto:rgetz@blackfin.uclinux.org] Sent: Saturday, June 16, 2007 12:11 AM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >On Wed 13 Jun 2007 12:37, Michael Shatz pondered: >> >> Hi Jean-Marc >> >> I'm trying to integrate your speex codec on our

-----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Tuesday, June 19, 2007 6:38 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >> Yes, data footprint in the new version is quite manageable. Still I would >> wish better documentation for speex_alloc_scratch(). >