Sourceforge CVS is up, but they moved it.
At the top of your CVS tree:
find . -type f -path '*/CVS/Root' -print0 | xargs -0 perl -p -i -e
's/\@(?:cvs\.)+/[EMAIL PROTECTED]/g;'
This _should_ work for anonymous CVS trackers as well, but I didn't test
it.
On Thu, 2006-05-11 at 21:15 -0400, Paul Al
On Wed, 2005-10-26 at 21:08 -0400, Paul Alfille wrote:
> On Wednesday 26 October 2005 04:37 pm, Marek Wodzinski wrote:
> > On Wed, 26 Oct 2005, Alfille, Paul H.,M.D. wrote:
> > > Ahhh... I'm sorta a software guy. 1=on 0=off
> > > Sorry for all the confusion.
> >
> > I'm a hardware based software gu
On Tue, 2005-10-18 at 10:28 -0400, Geo Carncross wrote:
> All of which makes exposing the synchronization primitives used by OW
> pretty much worthless.
I should clarify, that providing a common API to the language bindings
isn't bad, but requiring that they use them is- that is, h
On Mon, 2005-10-17 at 20:09 -0400, Paul Alfille wrote:
> This gets to a larger question: what should be internal to owlib, and what
> should be in ow.h that is used by other programs. In the past, the only
> direct clients of owlib were the included programs owfs., owhttpd,
> owserver, ... They
A mutual exclusion device is necessary.
OW_get, OW_put, and OW_finish all lock the common mutex.
If OW_get and OW_put /really can/ be used simultaneously, then a
condition is required:
in OW_get and OW_put:
LOCK(mutex);
level++;
UNLOCK(mutex);
{ real code }
LOCK(mutex);
level--;
SIGNAL(cond);
same time- is OW_get() reentrant, etc.
> -Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Geo
> Carncross
> Sent: Thursday, October 13, 2005 12:06 PM
> To: owfs-developers@lists.sourceforge.net
> Subject: RE: [Owfs-developers] New owc
On Thu, 2005-10-13 at 11:21 -0400, Alfille, Paul H.,M.D. wrote:
> Very nice work.
>
> Actually, OW_get is always null-terminated (we add an extra byte to the
> allocation and zero it), but not all values are strings (like memory from
> devices like the DS1993 are arbitrary data).
In these cases,
On Thu, 2005-10-13 at 06:45 -0400, Alfille, Paul H.,M.D. wrote:
> Oops, did my irony leak out? Can I retrieve it?
Paul, I know you despise being dragged through this :), so let me say
first that I appreciate you taking the time to examine this with me.
> I must admit sone mistification at the req
On Wed, 2005-10-12 at 13:17 -0400, Alfille, Paul H.,M.D. wrote:
> Concering "Multiple OW handles"
>
> I don't think the library, owlib, is set up for multiple invokation. All the
> global variables would colide.
>
> Let's see, that includes the input-device and output device chain heads
> (in_con
On Wed, 2005-10-12 at 08:17 +, Sven Geggus wrote:
> I would propose some kind of filehandle for the above functions and the swig
> Interface which would permit us using more than one bus from a given
> program.
I don't know how straightforward this is.
> I think this could look like this (for
On Tue, 2005-10-11 at 21:29 -0400, Paul Alfille wrote:
> > > int OW_get( const char * path, char * buffer, int buffer_length ) ;
> >
> > Don't let the programmer specify a buffer length for gets. It's prone to
> > programming errors. The extra malloc() isn't going to cause any real
> > problems, bu
re the user can step up the API as they need it.
Btw, specify in documentation:
OW_* calls aren't reetrant or thread-safe. Serialize yourself.
> Seems to work.
>
> Paul
>
> On Tuesday 11 October 2005 04:44 pm, Geo Carncross wrote:
> > On Fri, 2005-10-07 at 14:06
On Fri, 2005-10-07 at 14:06 -0400, Alfille, Paul H.,M.D. wrote:
> Sven,
>
> It would be easy to do. The real problem is string handling. We'd have to
> specify buffers and lengths.
Why?
int get_value(const char *path, char **ret, unsigned int *retlen);
Would be adequate and not require a buffer
Nevermind my previous retardation. :)
I tracked this down a while ago, it was libtool doing it. It's a
development requirement.
On my systems, libstdc++ doesn't get pulled in:
arthur:~$ ldd /opt/owfs/bin/owhttpd
libow.0 => /opt/owfs//lib/libow.0 (0x40018000)
libpthread.so.0 => /l
Remove AC_PROG_CXX from configure.ac?
It doesn't break anything here, but I don't/can't test every
configuration.
On Wed, 2005-09-14 at 15:06 -0400, Alfille, Paul H.,M.D. wrote:
> OWFS is entirely in C. (With perl,PHP,python,tcl for the language bindings.)
>
> How do we eliminate C++ requiremen
On Tue, 2005-04-19 at 11:09 -0400, Paul Alfille wrote:
> The bad news: NFS seems to depend on a filehandle. It is an opaque 64 byte
> structure. We'll have to generate it for every path and verify it with every
> access, since it goes to and from the client.
It doesn't just seem to. The NFS "vno
http://cr.yp.to/ftp.html
Good info for clients as well, I suppose...
On Thu, 2005-04-14 at 15:22 -0400, Geo Carncross wrote:
> NLST lists file _names_ (one per line). LIST should have a EPLF or UNIX-
> style output.
>
> Also note that mlsd and mlst are starting to appear in FTP c
NLST lists file _names_ (one per line). LIST should have a EPLF or UNIX-
style output.
Also note that mlsd and mlst are starting to appear in FTP clients. They
solve the problem that EPLF was designed to solve in a more obnoxious
fashion.
On Thu, 2005-04-14 at 01:18 +0200, Christian Magnusson wr
WARNING: COMPLETELY NON-OWFS RELATED.
but read on if you're battling these problems on embedded devices too...
On Wed, 2005-04-13 at 17:33 +0200, Christian Magnusson wrote:
> The WRT54G router use busybox, and therefor it's a huge binary to start.
> Resident memory is about 480kb when starting /
On Tue, 2005-04-12 at 10:41 +0200, Christian Magnusson wrote:
> Sure... It's an easy way to solve it, but when you are running things
> on embedded systems you have to save your ram wherever you can.
> Just starting /bin/sh will consume 484Kb on your WRT54G router... and
> that's a lot when you onl
I thought sourceforge already kept an archive?
On Thu, 2005-03-31 at 20:20 -0500, Paul Alfille wrote:
> I've signed up this mail list (owfs-developers) to be mirrored at
> http://www.mail-archive.com
>
> This is a searchable repository.
>
> The mail list is also mirrored at gmane (http://www.gm
21 matches
Mail list logo
