libphidget-devel — Mailing list for developers of libphidget

[Libphidget-devel] Library structure?

[Vadim T. <vt...@fr...>]

Hello,

Come to think of it, the phidgets code will always be a library - would it
be C or C++... right? So, to make this stuff more clear, I'd do this:

./src/libphidget	C library
./src/phidget++		C++ library
./src/examples		everything else

?

--vt

Re: [Libphidget-devel] Merging back?

[Jack S. <js...@ja...>]

On Sat, 2002-09-07 at 15:14, Vadim Tkachenko wrote:
> According to Jack Strohm:
> 
> > > Are you comfortable with the MULTIPLATFORM branch now? If yes, I'd like to
> > > merge it back to the main branch - is it OK with you?
> > 
> > yeah, everything looks ok in it.  I fixed that doc problem and
> > everything compiles great.
> 
> Done, check it.

compiles fine.  thanks.

Re: [Libphidget-devel] Merging back?

[Vadim T. <vt...@fr...>]

According to Jack Strohm:

> > Are you comfortable with the MULTIPLATFORM branch now? If yes, I'd like to
> > merge it back to the main branch - is it OK with you?
> 
> yeah, everything looks ok in it.  I fixed that doc problem and
> everything compiles great.

Done, check it.

--vt

Re: [Libphidget-devel] Merging back?

[Jack S. <js...@ja...>]

On Sat, 2002-09-07 at 15:01, Vadim Tkachenko wrote:
> Jack,
> 
> Are you comfortable with the MULTIPLATFORM branch now? If yes, I'd like to
> merge it back to the main branch - is it OK with you?

yeah, everything looks ok in it.  I fixed that doc problem and
everything compiles great.

[Libphidget-devel] Merging back?

[Vadim T. <vt...@fr...>]

Jack,

Are you comfortable with the MULTIPLATFORM branch now? If yes, I'd like to
merge it back to the main branch - is it OK with you?

--vt

Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Sat, 2002-09-07 at 02:30, Vadim Tkachenko wrote:
> According to Jack Strohm:
> > On Sat, 2002-09-07 at 00:20, Vadim Tkachenko wrote:
> > > > > Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
> > > > > years in Java and got eventually fed up with it for one simple reason: it's
> > > > > BIG. OK, you can put together something in a day that you'd spend a month
> > > > > doing in C++ (collections, threading, etc.), fine, but the weight of the
> > > > > resulting code is just overwhelming.
> > > > 
> > > > when you say weight, what do you mean?
> > > 
> > > In particular, memory footprint. Speed is not encouraging, either. Maybe
> > > it's just me with my tendency to write generic code and not optimize it, I
> > > don't know.
> > 
> > memory . . . you mean it takes more than 512 megs to run?  I figure
> > anything under 512 megs is pretty light  ;-)
> 
> 40-60M for a process that is supposed to be "just one of the daemons" is way
> too much...

I don't expect this library to take more than 100k when done, hopefully
much less.

Re: [Libphidget-devel] Documentation?

[Vadim T. <vt...@fr...>]

According to Jack Strohm:
> On Sat, 2002-09-07 at 00:20, Vadim Tkachenko wrote:
> > > > Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
> > > > years in Java and got eventually fed up with it for one simple reason: it's
> > > > BIG. OK, you can put together something in a day that you'd spend a month
> > > > doing in C++ (collections, threading, etc.), fine, but the weight of the
> > > > resulting code is just overwhelming.
> > > 
> > > when you say weight, what do you mean?
> > 
> > In particular, memory footprint. Speed is not encouraging, either. Maybe
> > it's just me with my tendency to write generic code and not optimize it, I
> > don't know.
> 
> memory . . . you mean it takes more than 512 megs to run?  I figure
> anything under 512 megs is pretty light  ;-)

40-60M for a process that is supposed to be "just one of the daemons" is way
too much...

> > > > And the real world applications of phidgets will most probably be MT.
> > > 
> > > why do they need to be MT?  
> > 
> > 'cause it's simpler this way.
> 
> I'd disagree about MT being simpler.  Maybe the design might be simpler,
> but the implementation of the design can have a lot of snafu's

I hope I'm done and over with snafu's. Just give me a little more time, I'll
port it back ;)

--vt

Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Sat, 2002-09-07 at 00:20, Vadim Tkachenko wrote:
> > > Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
> > > years in Java and got eventually fed up with it for one simple reason: it's
> > > BIG. OK, you can put together something in a day that you'd spend a month
> > > doing in C++ (collections, threading, etc.), fine, but the weight of the
> > > resulting code is just overwhelming.
> > 
> > when you say weight, what do you mean?
> 
> In particular, memory footprint. Speed is not encouraging, either. Maybe
> it's just me with my tendency to write generic code and not optimize it, I
> don't know.

memory . . . you mean it takes more than 512 megs to run?  I figure
anything under 512 megs is pretty light  ;-)

> 
> > > And the real world applications of phidgets will most probably be MT.
> > 
> > why do they need to be MT?  
> 
> 'cause it's simpler this way.

I'd disagree about MT being simpler.  Maybe the design might be simpler,
but the implementation of the design can have a lot of snafu's

>  
> > I always thought MT was very cool, but the large the system the harder
> > MT seems to be to deal with. (specially if your OS has thread bugs,
> > *solaris*, *windows*).
> 
> OS bugs notwithstanding, but I've figured out a way to deal with threads.
> Another project of mine, Jukebox, was multithreaded on OS/2 (the
> implementation was C++ back then), then I've ported it to Java and I'm
> afraid I've lost the C++ sources, but I'm seriously thinking about
> implementing those patterns in C++ again, now that the collections are
> basically standard (STL, right?).

yep, we got vectors (like collections), sets (sorted collections), map
(indexed collections) and a few more.  I really like templates, although
I sometimes don't like the consistency of the STL interface.

>  
> > I'm actually having a threading issue in another project.  A 3D graphics
> > engine I wrote that has 2 threads.  One draws everything, the other does
> > all the heavy LOD
> 
> What's LOD?

Level of Detail. 

http://iris.homeip.net:8080/jstrohm/index.jsp?Page=geek

( *beware of shameless plug of other project )

> 
> > calculations.  Runs very smooth in Linux.  I ported it to windows and it
> > is CRAP.  the background thread gets schedules about every few seconds for
> > about 100th of a second.  If you increase the threads priority any it
> > nearly locks the machine up cause the kernel can't get any time to
> > process.
> 
> Tried mutexes? Or event semaphores? Or the background calculations are
> *really* non-stop? Give me a little while, I might be able to help you with
> that...

Actually I designed it so it doesn't share much data between the two
threads so only one spot requires mutexes and it only get's called every
once in awhile.  So if you got 2 CPU's 99.9% of the time it never waits
on the other thread.  

Basically I lock mutex, change pointer to world data, unlock mutex
(kinda)

I think the slowdown in windows is just bad OS.  It works GREAT in
linux, it's probably about 2 to 3 times faster (on the same machine)

Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Fri, 2002-09-06 at 23:41, fit...@ph... wrote:
> 
> > I also have the concept of a "unique device", of which a phidget is one
> > of.  Servo's are unique devices, digital I/O, etc.  All unique devices a
> > a unique identification number to locate them, for phidgets this is
> > there USB serial number.  (btw - remember serial number is only unique
> > within vendor Id's, I think)
> 
> I've been trying to keep serial numbers unique, across all the phidgets.
> A few of the originals may not be.  Anything sold through the online store
> will be unique.
> 
> Chester

good.  :-)

Re: [Libphidget-devel] Documentation?

[Vadim T. <vt...@fr...>]

According to Jack Strohm:
> On Fri, 2002-09-06 at 23:01, Vadim Tkachenko wrote:
> > According to Jack Strohm:
> > 
> > > So that's why it's just phidgets and not all USB devices.  There are other
> > > USB drivers for other devices.  I wanted to abstract away the entire USB
> > > API so the user wasn't exposed to it (cause it can get a little weird).
> > 
> > I'm with you here... Almost ended up rewriting the USB subset for Java, and
> > the only thing that prevented me from doing it was lack of time and the fact
> > that I've finished scratching my itch.
> 
> I wish USB was a bit simpler, that's what I'm trying to provide for the
> user.  I don't like the interfaces, different ways to read and write
> data, I just want a stupid file handle or a socket, but that's not how
> USB works, oh well.

Agreed.
 
> > Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
> > years in Java and got eventually fed up with it for one simple reason: it's
> > BIG. OK, you can put together something in a day that you'd spend a month
> > doing in C++ (collections, threading, etc.), fine, but the weight of the
> > resulting code is just overwhelming.
> 
> when you say weight, what do you mean?

In particular, memory footprint. Speed is not encouraging, either. Maybe
it's just me with my tendency to write generic code and not optimize it, I
don't know.

> > And the real world applications of phidgets will most probably be MT.
> 
> why do they need to be MT?  

'cause it's simpler this way.
 
> I always thought MT was very cool, but the large the system the harder
> MT seems to be to deal with. (specially if your OS has thread bugs,
> *solaris*, *windows*).

OS bugs notwithstanding, but I've figured out a way to deal with threads.
Another project of mine, Jukebox, was multithreaded on OS/2 (the
implementation was C++ back then), then I've ported it to Java and I'm
afraid I've lost the C++ sources, but I'm seriously thinking about
implementing those patterns in C++ again, now that the collections are
basically standard (STL, right?).
 
> I'm actually having a threading issue in another project.  A 3D graphics
> engine I wrote that has 2 threads.  One draws everything, the other does
> all the heavy LOD

What's LOD?

> calculations.  Runs very smooth in Linux.  I ported it to windows and it
> is CRAP.  the background thread gets schedules about every few seconds for
> about 100th of a second.  If you increase the threads priority any it
> nearly locks the machine up cause the kernel can't get any time to
> process.

Tried mutexes? Or event semaphores? Or the background calculations are
*really* non-stop? Give me a little while, I might be able to help you with
that...

--vt

Re: [Libphidget-devel] Documentation?

[<fit...@ph...>]

> I also have the concept of a "unique device", of which a phidget is one
> of.  Servo's are unique devices, digital I/O, etc.  All unique devices a
> a unique identification number to locate them, for phidgets this is
> there USB serial number.  (btw - remember serial number is only unique
> within vendor Id's, I think)

I've been trying to keep serial numbers unique, across all the phidgets.
A few of the originals may not be.  Anything sold through the online store
will be unique.

Chester

Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Fri, 2002-09-06 at 23:01, Vadim Tkachenko wrote:
> According to Jack Strohm:
> 
> > On Fri, 2002-09-06 at 21:37, Vadim Tkachenko wrote:
> > > Jack Strohm wrote:
> 
> > > - What happens if wrong arguments are supplied (suppose, someone
> > > deallocated the phidget_type and forgot to discard the reference, and
> > > called a function again)?
> > 
> > since users don't allocate phidget_type they shouldn't ever deallocate
> > them.  
> 
> "shouldn't" and "wouldn't" are different things ;) As a paranoid type, I'd
> go as far as checking the heap (if it is accessible, of course) for the
> pointers to those phidget_type objects... I need to get my memories about
> C/C++ back, then I'd be able to give an educated guess on how to do it.

That does seem a bit extreme.  I can't really stop them from
deallocating any memory they aren't supposed to.  I mean you can type
free(234234); and it will compile, and maybe even run and deallocate
valid memory.  

I think that would be classified as a bug in their program, and not
mine, so I don't see why I should spend time guarding for it.  I do
agree with being careful (which is why the data structures are not
public), but I can't protect the user from all mistakes.

> 
> > > Let me play a devil's advocate for a while...
> > 
> > uh-oh, let me get my crosses and holy water  ;-)
> 
> Get some more ;)
> 
> > > > PhidgetManager's main reason for existence:
> > > > 
> > > >         1) it knows about all phidget devices on the system.  The user can
> > > > query for the existence of certain types of phidgets or for a specific
> > > > phidget and the manager handles this query.
> > > 
> > > Suppose I'm the user. Do I really care if it is a Phidget? Not really...
> > > To me, this is a USB device that just happens to be a Phidget, that's
> > > all. What I care about, instead, is that when this USB device arrives,
> > > its capabilities are accessible, and it would be a good thing if the
> > > arrival is announced. Possibly together with some device initialization,
> > > and possibly I'd like to have some persistent properties of this device
> > > restored.
> > 
> > I was looking at it from another point of view.  I own phidgets, I want
> > to interact with them.  I don't care that they are USB, I want to know
> > when they attach/detach, I want there firmware to be uploaded, and I
> > want to be able have a simple way to access all of there accessories. 
> > This was never meant to be generic beyond phidgets.
> 
> OK, good, now we're getting some use cases for the phidgets.
> 
> 1. read
> 2. write
> 3. upload firmware
> 4. receive arrival notification
> 5. receive departure notification
> 6. receive property change notification (?)

yes, while this is all done at the libphidget.so C library and not in
the C++ library.

> 
> What else?

hmmm, that seems to cover the general cases of what phidgets do.  

I also have the concept of a "unique device", of which a phidget is one
of.  Servo's are unique devices, digital I/O, etc.  All unique devices a
a unique identification number to locate them, for phidgets this is
there USB serial number.  (btw - remember serial number is only unique
within vendor Id's, I think)

> 
> > > All abovesaid somehow makes me think about the kernel drivers, though
> > > ;)))
> > 
> > Why is that?  I actually started playing with kernel drivers, but I kept
> > getting everyone telling me to stay in user space.
> 
> Funny question: is it possible to have a device driver that is running in
> user space?

Yes, libusb provides a generic interface in user space to access USB
devices.  This project will handle firmware updates and the various
communication protocols needed to get the devices to be functional.

> 
> > > Give you an example: if I have an LCD phidget, I'd probably like to
> > > treat it as a stream device supporting ANSI escapes so I can position
> > > the text and/or set the colors, if it is color... If it is an RFID (let
> > > me speculate that RFID is a chip that can be "scanned", exactly as the
> > > items are scanned on a checkout line in the store), then I'd probably
> > > like to have the device that will just send me arrival notifications
> > > from the RFID chips...
> > 
> > that is what I'd like to implement.  Although I don't have any input
> > devices to play with. (please Chester send me some!)
>  
> An example I forgot about when I was writing the previous message:
> 
> /dev/phidget/servo
>                   /controller/<id>
>                                   /propeties
>                                   /servo/<id>
>                                              /properties
>                                              /stream
>                                   
> 
> Something like that.

That's what I was originally going for, but the usb device driver guys
seemed to think I'd be better served using libusb.  I get the same
functionality, libusb does:

/proc/bus/usb
             /devices (text file)
             /drivers (text file)
             /001
                /001 (device 1 on bus 1)
             /002
                /001 (device 1 on bus 2)
                /002 (device 2 on bus 2)

I basically connect to these devices and use them.


> 
> > > (granted, the RFID example was farfetched, I have no idea how it works)
> 
> If I guessed it right, then
> 
> /dev/phidget/rfid/<id>
>                       /properties
>                       /stream

see they way I see it is:

PhidgetManager = /dev/phidget
PhidgetServo = /dev/phidget/servo/controller/<id>
Servo = /dev/phidget/servo/controller/<id>/servo/<id>

Now I know these aren't accessible at the shell level.

> 
> > The Phidget manager is a "singleton" object, there is one, and can only
> > be one created, if you access it, it is created automatically.
> 
> Damn, C++ guys have it easy - in Java, there's always a possibility to end
> up with multiple "singletons" if you start fiddling with class loaders, and
> there's always a possibility that you're not the only who tries to
> instantiate the same singleton, often with different parameters -
> singletones and Java just don't mix...

It took me awhile of searching before I found a singleton template
example that I was happy with.

> 
> > > But, if you talk about introspection, then the picture changes... I'd
> > > rather be able to walk the device tree and find all the abstractions,
> > > but again, does it have to be a Phidget or a generic USB device? Open to
> > > speculation...
> > 
> > Well this project is just for interacting with phidgets.
> 
> Well, probably, but the phidgets are more than just toys - they're real
> world devices, and it's quite possible that some people (count me in) will
> try to treat them as grown-up things ;)

I'm not saying that they will be toys (although I plan on "playing" with
them).  I'm just saying that the point of this library is to interface
with phidgets, anything more is for another library.  


> > So that's why it's just phidgets and not all USB devices.  There are other
> > USB drivers for other devices.  I wanted to abstract away the entire USB
> > API so the user wasn't exposed to it (cause it can get a little weird).
> 
> I'm with you here... Almost ended up rewriting the USB subset for Java, and
> the only thing that prevented me from doing it was lack of time and the fact
> that I've finished scratching my itch.

I wish USB was a bit simpler, that's what I'm trying to provide for the
user.  I don't like the interfaces, different ways to read and write
data, I just want a stupid file handle or a socket, but that's not how
USB works, oh well.

> > > Another thing I don't know how to approach - in Java, one is spoiled
> > > with listeners and asynchronous notifications. In C++, this will involve
> > > multithreading context, which I'm not ready to take on 'cause last time
> > > I've touched it was in OS/2 in 1994... Can you shed some light on this,
> > > please?
> > 
> > Me and a friend thought about this a lot, and we decided just polling
> > for events would be easier to implement and get the job done just as
> > well.  Most applications aren't MT.
> 
> Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
> years in Java and got eventually fed up with it for one simple reason: it's
> BIG. OK, you can put together something in a day that you'd spend a month
> doing in C++ (collections, threading, etc.), fine, but the weight of the
> resulting code is just overwhelming.

when you say weight, what do you mean?

> 
> Now, I feel that I'm not the only one... And people who turn back to C++
> from Java *are* spoiled - all in all, it's a beautiful environment. I want
> my threads. I want my semaphores. I want my <name it>.

I'm actually been looking at doing some projects in java (jsp/EJB and
all that crap)

> 
> And the real world applications of phidgets will most probably be MT.

why do they need to be MT?  

I always thought MT was very cool, but the large the system the harder
MT seems to be to deal with. (specially if your OS has thread bugs,
*solaris*, *windows*).

I'm actually having a threading issue in another project.  A 3D graphics
engine I wrote that has 2 threads.  One draws everything, the other does
all the heavy LOD calculations.  Runs very smooth in Linux.  I ported it
to windows and it is CRAP.  the background thread gets schedules about
every few seconds for about 100th of a second.  If you increase the
threads priority any it nearly locks the machine up cause the kernel
can't get any time to process.

Re: [Libphidget-devel] Documentation?

[Vadim T. <vt...@fr...>]

According to Jack Strohm:

> On Fri, 2002-09-06 at 21:37, Vadim Tkachenko wrote:
> > Jack Strohm wrote:

> > - What happens if wrong arguments are supplied (suppose, someone
> > deallocated the phidget_type and forgot to discard the reference, and
> > called a function again)?
> 
> since users don't allocate phidget_type they shouldn't ever deallocate
> them.  

"shouldn't" and "wouldn't" are different things ;) As a paranoid type, I'd
go as far as checking the heap (if it is accessible, of course) for the
pointers to those phidget_type objects... I need to get my memories about
C/C++ back, then I'd be able to give an educated guess on how to do it.

> > Let me play a devil's advocate for a while...
> 
> uh-oh, let me get my crosses and holy water  ;-)

Get some more ;)

> > > PhidgetManager's main reason for existence:
> > > 
> > >         1) it knows about all phidget devices on the system.  The user can
> > > query for the existence of certain types of phidgets or for a specific
> > > phidget and the manager handles this query.
> > 
> > Suppose I'm the user. Do I really care if it is a Phidget? Not really...
> > To me, this is a USB device that just happens to be a Phidget, that's
> > all. What I care about, instead, is that when this USB device arrives,
> > its capabilities are accessible, and it would be a good thing if the
> > arrival is announced. Possibly together with some device initialization,
> > and possibly I'd like to have some persistent properties of this device
> > restored.
> 
> I was looking at it from another point of view.  I own phidgets, I want
> to interact with them.  I don't care that they are USB, I want to know
> when they attach/detach, I want there firmware to be uploaded, and I
> want to be able have a simple way to access all of there accessories. 
> This was never meant to be generic beyond phidgets.

OK, good, now we're getting some use cases for the phidgets.

1. read
2. write
3. upload firmware
4. receive arrival notification
5. receive departure notification
6. receive property change notification (?)

What else?

> > All abovesaid somehow makes me think about the kernel drivers, though
> > ;)))
> 
> Why is that?  I actually started playing with kernel drivers, but I kept
> getting everyone telling me to stay in user space.

Funny question: is it possible to have a device driver that is running in
user space?

> > Give you an example: if I have an LCD phidget, I'd probably like to
> > treat it as a stream device supporting ANSI escapes so I can position
> > the text and/or set the colors, if it is color... If it is an RFID (let
> > me speculate that RFID is a chip that can be "scanned", exactly as the
> > items are scanned on a checkout line in the store), then I'd probably
> > like to have the device that will just send me arrival notifications
> > from the RFID chips...
> 
> that is what I'd like to implement.  Although I don't have any input
> devices to play with. (please Chester send me some!)
 
An example I forgot about when I was writing the previous message:

/dev/phidget/servo
                  /controller/<id>
                                  /propeties
                                  /servo/<id>
                                             /properties
                                             /stream
                                  

Something like that.

> > (granted, the RFID example was farfetched, I have no idea how it works)

If I guessed it right, then

/dev/phidget/rfid/<id>
                      /properties
                      /stream

> The Phidget manager is a "singleton" object, there is one, and can only
> be one created, if you access it, it is created automatically.

Damn, C++ guys have it easy - in Java, there's always a possibility to end
up with multiple "singletons" if you start fiddling with class loaders, and
there's always a possibility that you're not the only who tries to
instantiate the same singleton, often with different parameters -
singletones and Java just don't mix...

> > But, if you talk about introspection, then the picture changes... I'd
> > rather be able to walk the device tree and find all the abstractions,
> > but again, does it have to be a Phidget or a generic USB device? Open to
> > speculation...
> 
> Well this project is just for interacting with phidgets.

Well, probably, but the phidgets are more than just toys - they're real
world devices, and it's quite possible that some people (count me in) will
try to treat them as grown-up things ;)

> So that's why it's just phidgets and not all USB devices.  There are other
> USB drivers for other devices.  I wanted to abstract away the entire USB
> API so the user wasn't exposed to it (cause it can get a little weird).

I'm with you here... Almost ended up rewriting the USB subset for Java, and
the only thing that prevented me from doing it was lack of time and the fact
that I've finished scratching my itch.

> > Another thing I don't know how to approach - in Java, one is spoiled
> > with listeners and asynchronous notifications. In C++, this will involve
> > multithreading context, which I'm not ready to take on 'cause last time
> > I've touched it was in OS/2 in 1994... Can you shed some light on this,
> > please?
> 
> Me and a friend thought about this a lot, and we decided just polling
> for events would be easier to implement and get the job done just as
> well.  Most applications aren't MT.

Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
years in Java and got eventually fed up with it for one simple reason: it's
BIG. OK, you can put together something in a day that you'd spend a month
doing in C++ (collections, threading, etc.), fine, but the weight of the
resulting code is just overwhelming.

Now, I feel that I'm not the only one... And people who turn back to C++
from Java *are* spoiled - all in all, it's a beautiful environment. I want
my threads. I want my semaphores. I want my <name it>.

And the real world applications of phidgets will most probably be MT.

OK, done ranting.

> I do want to make it MT safe so
> that it won't prohibit you from using it in MT applications.

Cool ;)

--vt

Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Fri, 2002-09-06 at 21:37, Vadim Tkachenko wrote:
> Jack Strohm wrote:
> > 
> > On Fri, 2002-09-06 at 03:30, Vadim Tkachenko wrote:
> 
> > > - What integrity enforcement measures were embedded into the implementation?
> > 
> > Could you explain what you mean by this in more details.
> 
> - Is it possible to accidentally create more than one master list of
> phidgets?

Can't occur.

> - Is the library thread safe?

Not yet.  I have thought about it.

> - What happens if wrong arguments are supplied (suppose, someone
> deallocated the phidget_type and forgot to discard the reference, and
> called a function again)?

since users don't allocate phidget_type they shouldn't ever deallocate
them.  

> 
> This is easier done in C++ than in C, granted...
> 
> > > - (since I haven't seen the device docs yet) What are the features common to
> > >   all the Phidgets? Being pessimistic, so far I haven't seen any. Therefore,
> > >   a question - how justified is the PhidgetManager?
> > 
> > As for common features among all phidgets, all that I am aware of is the
> > ability to get the device's serial number.
> 
> But isn't this a generic USB feature?
> 

I think so.  But generic to USB is generic to phidget.


> Let me play a devil's advocate for a while...

uh-oh, let me get my crosses and holy water  ;-)

>  
> > PhidgetManager's main reason for existence:
> > 
> >         1) it knows about all phidget devices on the system.  The user can
> > query for the existence of certain types of phidgets or for a specific
> > phidget and the manager handles this query.
> 
> Suppose I'm the user. Do I really care if it is a Phidget? Not really...
> To me, this is a USB device that just happens to be a Phidget, that's
> all. What I care about, instead, is that when this USB device arrives,
> its capabilities are accessible, and it would be a good thing if the
> arrival is announced. Possibly together with some device initialization,
> and possibly I'd like to have some persistent properties of this device
> restored.

I was looking at it from another point of view.  I own phidgets, I want
to interact with them.  I don't care that they are USB, I want to know
when they attach/detach, I want there firmware to be uploaded, and I
want to be able have a simple way to access all of there accessories. 
This was never meant to be generic beyond phidgets.

> 
> All abovesaid somehow makes me think about the kernel drivers, though
> ;)))

Why is that?  I actually started playing with kernel drivers, but I kept
getting everyone telling me to stay in user space.

> 
> Give you an example: if I have an LCD phidget, I'd probably like to
> treat it as a stream device supporting ANSI escapes so I can position
> the text and/or set the colors, if it is color... If it is an RFID (let
> me speculate that RFID is a chip that can be "scanned", exactly as the
> items are scanned on a checkout line in the store), then I'd probably
> like to have the device that will just send me arrival notifications
> from the RFID chips...

that is what I'd like to implement.  Although I don't have any input
devices to play with. (please Chester send me some!)

> 
> (granted, the RFID example was farfetched, I have no idea how it works)
> 

I've been looking at the VB api to figure out the capabilities of the
devices (although I'm not copying that API)

> >         2) Dynamically allocates phidgets objects that the user doesn't want to
> > allocate himself, but may still need.  For example a user can create a
> > servo object that allows him to access a specific servo, but doesn't
> > have to create the phidget object manually.  The servo object is created
> > (either with new or on the stack).
> 
> Again, do I need to even know about the phidget manager in order to
> create a servo instance? I may need to be aware of the abstraction of
> the servo controller in case the servo controller, as an entity, offers
> some configuration, but to the best of my recollection at least the
> QuadServo is able to control the individual servo's properties, and the
> servo controller doesn't have any tuneups. So, in this case, I'd rather
> create the servo instance directly (based on the controller serial # and
> servo #) and work with it.

No you don't ever need to know the manager exists.  Currently the way
the C++ code works, you can do this 

main()
{
	CServo servo(CUID(741,0))

	servo.position(.5);
}

no manager needed, the manager it dynamically created the first time it
is needed.  Now if you wanted the Phidget Servo controller you can do
this:

main()
{
	CServoController controller(CUID(741));

	CServo *servo=controller.servo(0,true);

	servo->position(.5);
}

This does the same thing, with a bit more control, now we have access to
the servo controller. (actually this is bugged, but it will work soon).

The Phidget manager is a "singleton" object, there is one, and can only
be one created, if you access it, it is created automatically.  So, as a
user if you want it you can get it:

	CPhidgetManager *manager=CPhidgetManager::getInstance();

but if you don't want it, you don't even need to know it exists.

> 
> But, if you talk about introspection, then the picture changes... I'd
> rather be able to walk the device tree and find all the abstractions,
> but again, does it have to be a Phidget or a generic USB device? Open to
> speculation...

Well this project is just for interacting with phidgets.  So that's why
it's just phidgets and not all USB devices.  There are other USB drivers
for other devices.  I wanted to abstract away the entire USB API so the
user wasn't exposed to it (cause it can get a little weird).

> 
> Another thing I don't know how to approach - in Java, one is spoiled
> with listeners and asynchronous notifications. In C++, this will involve
> multithreading context, which I'm not ready to take on 'cause last time
> I've touched it was in OS/2 in 1994... Can you shed some light on this,
> please?

Me and a friend thought about this a lot, and we decided just polling
for events would be easier to implement and get the job done just as
well.  Most applications aren't MT.  I do want to make it MT safe so
that it won't prohibit you from using it in MT applications.

Re: [Libphidget-devel] Documentation?

[Vadim T. <vt...@fr...>]

Jack Strohm wrote:
> 
> On Fri, 2002-09-06 at 03:30, Vadim Tkachenko wrote:

> > - What integrity enforcement measures were embedded into the implementation?
> 
> Could you explain what you mean by this in more details.

- Is it possible to accidentally create more than one master list of
phidgets?
- Is the library thread safe?
- What happens if wrong arguments are supplied (suppose, someone
deallocated the phidget_type and forgot to discard the reference, and
called a function again)?

This is easier done in C++ than in C, granted...

> > - (since I haven't seen the device docs yet) What are the features common to
> >   all the Phidgets? Being pessimistic, so far I haven't seen any. Therefore,
> >   a question - how justified is the PhidgetManager?
> 
> As for common features among all phidgets, all that I am aware of is the
> ability to get the device's serial number.

But isn't this a generic USB feature?

Let me play a devil's advocate for a while...
 
> PhidgetManager's main reason for existence:
> 
>         1) it knows about all phidget devices on the system.  The user can
> query for the existence of certain types of phidgets or for a specific
> phidget and the manager handles this query.

Suppose I'm the user. Do I really care if it is a Phidget? Not really...
To me, this is a USB device that just happens to be a Phidget, that's
all. What I care about, instead, is that when this USB device arrives,
its capabilities are accessible, and it would be a good thing if the
arrival is announced. Possibly together with some device initialization,
and possibly I'd like to have some persistent properties of this device
restored.

All abovesaid somehow makes me think about the kernel drivers, though
;)))

Give you an example: if I have an LCD phidget, I'd probably like to
treat it as a stream device supporting ANSI escapes so I can position
the text and/or set the colors, if it is color... If it is an RFID (let
me speculate that RFID is a chip that can be "scanned", exactly as the
items are scanned on a checkout line in the store), then I'd probably
like to have the device that will just send me arrival notifications
from the RFID chips...

(granted, the RFID example was farfetched, I have no idea how it works)

>         2) Dynamically allocates phidgets objects that the user doesn't want to
> allocate himself, but may still need.  For example a user can create a
> servo object that allows him to access a specific servo, but doesn't
> have to create the phidget object manually.  The servo object is created
> (either with new or on the stack).

Again, do I need to even know about the phidget manager in order to
create a servo instance? I may need to be aware of the abstraction of
the servo controller in case the servo controller, as an entity, offers
some configuration, but to the best of my recollection at least the
QuadServo is able to control the individual servo's properties, and the
servo controller doesn't have any tuneups. So, in this case, I'd rather
create the servo instance directly (based on the controller serial # and
servo #) and work with it.

But, if you talk about introspection, then the picture changes... I'd
rather be able to walk the device tree and find all the abstractions,
but again, does it have to be a Phidget or a generic USB device? Open to
speculation...

Another thing I don't know how to approach - in Java, one is spoiled
with listeners and asynchronous notifications. In C++, this will involve
multithreading context, which I'm not ready to take on 'cause last time
I've touched it was in OS/2 in 1994... Can you shed some light on this,
please?

--vt

Re: [Libphidget-devel] Website (was Doxygen)

[Vadim T. <vt...@fr...>]

Hello,

> > - Make your website documents integral part of your CVS repository
> 
> it is

Damn, I'm getting sloppy... Yes, it is. However, it is not a part of the
distribution - so whoever downloads the package, doesn't get the docs along
with it, except for Doxygen docs.
 
--vt

Re: [Libphidget-devel] Doxygen

[Jack S. <js...@ja...>]

On Fri, 2002-09-06 at 20:33, Vadim Tkachenko wrote:
> Hello,
> 
> It seems that Doxygen is not going to happen at my workstation anytime soon
> - it needs at least qt-devel-2.3.0, which, in turn, wants XFree86 4.0.2, and
> I just don't have time to upgrade THAT right now, so, Jack, you'll have to
> polish the rest of it - by now, it should work.
> 
> Another thing to think about - the site layout.
> 
> You can save yourself a good deal of maintenance if you do this:
> 
> - Make your website documents integral part of your CVS repository

it is

> - Have index.html at the top level of the project directory, and the rest
>   somewhere else - say, in ./docs
> 
> This way, you
> 
> - Provide the complete documentation along with the source, for those
>   unfortunate that still have dialups
> 
> - Keep the website in the CVS as well as the code ;)
> 
> - Don't need to manually fix the website if you just install a cron job on
>   SourceForge box that will pull the contents of the CVS into the
>   DocumentRoot once in an hour :)

yeah

[Libphidget-devel] Doxygen

[Vadim T. <vt...@fr...>]

Hello,

It seems that Doxygen is not going to happen at my workstation anytime soon
- it needs at least qt-devel-2.3.0, which, in turn, wants XFree86 4.0.2, and
I just don't have time to upgrade THAT right now, so, Jack, you'll have to
polish the rest of it - by now, it should work.

Another thing to think about - the site layout.

You can save yourself a good deal of maintenance if you do this:

- Make your website documents integral part of your CVS repository
- Have index.html at the top level of the project directory, and the rest
  somewhere else - say, in ./docs

This way, you

- Provide the complete documentation along with the source, for those
  unfortunate that still have dialups

- Keep the website in the CVS as well as the code ;)

- Don't need to manually fix the website if you just install a cron job on
  SourceForge box that will pull the contents of the CVS into the
  DocumentRoot once in an hour :)

Comments?

--vt

[Libphidget-devel] CUID.cc:42

[Vadim T. <vt...@fr...>]

Jack,

Here's the persisting warning:

CUID.cc: In method onst CUID &CUID::operator= (const CUID &)':
CUID.cc:42: warning: no return statement in function returning non-void

Here's the code:

const CUID &CUID::operator=(const CUID &id)
{
        _serial=id._serial;
        _id=id._id;
}

Do I remember right that this operator is supposed to return a reference to
'this'?

Another thing: I'll take a look at gcc manual and jack up all the possible
warnings... Better safe than sorry.

--vt

[Libphidget-devel] Broken build

[Vadim T. <vt...@fr...>]

Hello,

Main branch:

c++ -g -c CPhidget.cc -I../libphidget
In file included from CUniqueDevice.h:12,
                 from CPhidget.h:13,
                 from CPhidget.cc:10:
CUID.h: In method tring CUID::asString () const':
CUID.h:110: printf' undeclared (first use this function)
CUID.h:110: (Each undeclared identifier is reported only once for each 
function it appears in.)
In file included from CUniqueDevice.h:14,
                 from CPhidget.h:13,
                 from CPhidget.cc:10:
/usr/include/stdio.h: At top level:
/usr/include/stdio.h:281: 	nt sprintf (char *, const char *, ...)' 
used prior to declaration
make: *** [CPhidget.o] Error 1

--vt

[Libphidget-devel] Documentation?

[Vadim T. <vt...@fr...>]

Hello there,

Besides the device documentation (I know some is coming), were there any
architecture/UML/other diagrams for the *code*?

I'm looking at phidget.c/h right now and thinking - 

- Has the state machine for the driver been defined?

- What integrity enforcement measures were embedded into the implementation?

- (since I haven't seen the device docs yet) What are the features common to
  all the Phidgets? Being pessimistic, so far I haven't seen any. Therefore,
  a question - how justified is the PhidgetManager?

I'd prefer to get to the latest thing later, when I do have the docs. Quite
probably, I'll find the answers to these questions myself, but your
suggestions are appreciated.

--vt

[Libphidget-devel] Coding conventions...

[Vadim T. <vt...@fr...>]

Hello there,

Every programmer has their favorites ;) There are no two people alike.

Therefore proposal:

In order to make the code readable for everybody, integrate the indent(1),
which, I believe, is now a standard part of a distribution, at least on
Linux. This way,

- You can keep all the code in the CVS in a single style
- You can keep the code you've checked out in *your own*

Everybody's happy.

Comments?

--vt