Linux-Development-Apps Digest #669, Volume #6 Wed, 31 May 00 16:13:14 EDT
Contents:
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: lockf problems... (fred smith)
Re: Code improvements in timing loops? (Kaz Kylheku)
Re: Code improvements in timing loops? (fprintf)
Re: Code improvements in timing loops? (fprintf)
Re: lockf problems... ([EMAIL PROTECTED])
Re: Need ideas for university funded project for linux (Yarick Rastrigin)
Qt based note editor with midi import (Dr. Joerg Anders)
Re: PS Editor? (Andreas Kahari)
Re: Code improvements in timing loops? (Kaz Kylheku)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: PS Editor? (Terje Tverberg)
Re: Threads or process? (Roland)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.system,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 31 May 2000 16:10:59 GMT
On Wed, 31 May 2000 15:59:59 GMT, David Steuber <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (JEDIDIAH) writes:
>
>' >A database is the only way to really solve this problem with any
>' >speed. Sure, you could find(1) all executables and ldd them to see
>' >which libraries they use, but what a waste of time. It won't even
>'
>' No it isn't. Such a practice would tell you what is ACTUALLY
>' on the system rather than what has been made known to the debian
>' or rpm databases.
>
>I use updatedb and locate rather a lot. Updatedb is run from
>cron.daily ( I think ). It doesn't seem like such a stretch to then
>do a file command on each entry in the locate database to see if it is
>an elf and if so what it ldds.
>
>Seems like something a sh script can do.
Certainly. Just rebuild the db at 3am when the system is idle
and the end user is asleep...
I was also thinking that this could be added to the filesystem
in some way. Applications could create a sort of hard link to
any file that was dependent on. Of course that 'hard link' would
go away with the file that owned it. This could serve as a reference
counter exposed to the OS at the lowest level possible.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: fred smith <[EMAIL PROTECTED]>
Subject: Re: lockf problems...
Date: Wed, 31 May 2000 10:57:01 GMT
bytes2go <[EMAIL PROTECTED]> wrote:
: Hi Everyone ,
: I am a Unix Admin for a software developer in the midwest. We
: recently setup a Linux server (RH 6.2) for our software
: engineers to port one of our products over to Linux. They are
: having a problem with a "lockf" (LockFile?) command not working
: the same as it does on other Unixes. Anyone Have nay ideas where
: they can get support help with this???
: If you do, please contact me @ [EMAIL PROTECTED] and I will
: forward your e-mail address to the programmer...
: Thanks,
Last I noticed Linux didn't have a lockf(). A few years ago I wrote
one, but all it is is a wrapper around fcntl. Probably the best way
in the long term for your engineers to deal with it is to replace
calls to lockf with appropriate calls to fcntl().
If you __really__ want a lockf, let me know perhaps I could be talked
into letting you have mine.
Fred
--
---- Fred Smith -- [EMAIL PROTECTED] ----------------------------
I can do all things through Christ
who strengthens me.
============================== Philippians 4:13 ===============================
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Code improvements in timing loops?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 31 May 2000 16:22:26 GMT
On Wed, 31 May 2000 04:19:59 -0400, Robichaud, Jean-Philippe [BAN:6S33:EXCH]
<[EMAIL PROTECTED]> wrote:
>Here is a little change that will do a little difference, saving you
>couple cycles. Rewriting the entire procedure in C is a good idea. I
>also suggest that you write a simpler/much faster version of
>gettimeofday because you don't really need the time of the day, you need
>difference between 2 time points and that is different.
>
>> for (int i = 64;i > 4; i=i/2)
> should become : for (int i= 64; ! (i&4); i << 1)
>
> Hope this will help.
Don't be silly. Any modern compiler whose use is worth even contemplating will
handle multiplications and divisions by a power of two in some efficient way,
such as by using shifts.
In some cases, the best power reduction is achieved if you use an unsigned
type, so the compiler doesn't have to worry about negative values.
E.g. i % 64 can simplify into i & 63 only if i is an unsigned type, or
the compiler can otherwise deduce that the value is always positive.
--
#exclude <windows.h>
------------------------------
Subject: Re: Code improvements in timing loops?
From: fprintf <[EMAIL PROTECTED]>
Date: Wed, 31 May 2000 10:31:43 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>You might want to keep track of approximately where the cars
are on
>the track. Thousanths of a sccond only count when two cars
reach the
>timer at the same time. If a car has passed within the last
couple of
>seconds, you don't need to check that lane again until
approximately a
>laptime has passed.
And here I was trying to be efficient and use a boolean value
for whether a car had passed overhead. I have seen other
programs (written for DOS) that use approximate lap times and a
simple if (time > 5 seconds) { check the lane to see if a car is
there }. I considered it poor programming at the time, but now
it seems to make sense to avoid checking the same lane
repeatedly. :-)
>Update the screen "between" cars.
Thanks for that one. I always figured the function call and
extra logic required for doing this was more expensive than
doing it within the same loop. Especially because there may be
times when three cars pass the sensors, but another falls off
the track, therefore possibly not triggering the screen update.
>
>You don't care about the thousanths until the last lap. Stop
updating
>the screen when you are expecting cars across the finish line.
That is not entirely true. There are reasons to accurately time
each lap, specifically for keeping track of lap records.
>
>Another option, for photo finishes, add some logic to your
sensors to
>ensure that the first car across the sensor is the first line
>triggered to your computer. You could set an output to your
logic
>circuit on the last lap to enable the "lockout/sequence"
function.
Very interesting! I had thought about this, but had no idea how
to code so that I was checking each sensor rapidly enough to
lockout the other lanes. I think I may get to this using all
the suggestions in the thread thus far for speeding up my timing
loops, and moving some of the screen updating stuff outside the
timing loop.
>
>ads
Thank you very much!
Stuart
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Code improvements in timing loops?
From: fprintf <[EMAIL PROTECTED]>
Date: Wed, 31 May 2000 10:35:04 -0700
In article <[EMAIL PROTECTED]>, "Robichaud,
Jean-Philippe [BAN:6S33:EXCH]" <[EMAIL PROTECTED]>
wrote:
>Here is a little change that will do a little difference,
saving you
>couple cycles. Rewriting the entire procedure in C is a good
idea. I
>also suggest that you write a simpler/much faster version of
>gettimeofday because you don't really need the time of the day,
you need
>difference between 2 time points and that is different.
Ok, I know that it takes at least 22 microseconds on my 486 for
a call to gettimeofday(), and I have to do it at least 4 times
each time a car is overhead one or more of the sensors. So this
could be where I am getting a little slow down. However, can
you suggest a place where I can get some code for my own,
quicker, timing loops? I am only using gettimeofday() because
it is the place where I can access microseconds.
thanks!
Stuart
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: lockf problems...
Date: Wed, 31 May 2000 17:52:16 GMT
fred smith <[EMAIL PROTECTED]> wrote:
> Last I noticed Linux didn't have a lockf(). A few years ago I wrote
> one, but all it is is a wrapper around fcntl. Probably the best way
> in the long term for your engineers to deal with it is to replace
> calls to lockf with appropriate calls to fcntl().
I second this approach, fcntl() locking is specified in POSIX.1 where
as lockf() is barely existant any more. So, moving to fcntl will save
you headaches down the road even on non-linux platforms.
For a good discussion of file locking issues, see the nutshell book
_Porting Unix Software_ which includes a large section on the subject.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Yarick Rastrigin <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.system,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Wed, 31 May 2000 21:52:40 +0400
Reply-To: [EMAIL PROTECTED]
Hello !
> >
> >Seems like something a sh script can do.
>
> Certainly. Just rebuild the db at 3am when the system is idle
> and the end user is asleep...
I for myself always hate this behavior. It's not uncommon in our company
to work through
the night, and updatedb slowing things down usually in the middle of
hard debugging session
pisses me off. And when it runs throuhg network mounts with 20 to 100
Gb's SMB-mounted disks
all across our local network - it's waay too long to complete, so it's
better to
killall find. Or servers, running database speed test (1 million of
insert/select) show strange and different results, especially if all
session uses 10-12 hours - depending of when it was started...
>
> I was also thinking that this could be added to the filesystem
> in some way. Applications could create a sort of hard link to
Certainly, could be. I think some unused bits in filedescriptor could
hold at least major
info about filetype. But it would add an unneeded complicacy to fsck ,
and in case of
fs corruption this could create a mess.
> any file that was dependent on. Of course that 'hard link' would
> go away with the file that owned it. This could serve as a reference
> counter exposed to the OS at the lowest level possible.
>
> --
>
> In what language does 'open' mean 'execute the evil contents of' |||
> a document? --Les Mikesell / | \
>
> Need sane PPP docs? Try penguin.lvcm.com.
--
With all the best, [EMAIL PROTECTED] AKA 2:5025/17
------------------------------
From: [EMAIL PROTECTED] (Dr. Joerg Anders)
Subject: Qt based note editor with midi import
Date: 31 May 2000 18:26:19 GMT
Version 1.5.0 of the note editor on Linux (GPL, beta) is ready:
http://rnvs.informatik.tu-chemnitz.de/~ja/noteedit/noteedit.html
New feature
============
- Import Midi
There are still some restrictions but I imported from Classical Midi Archive
(http://prs.net/midi.html)
+ the 1st movement of Beethoven's 5th symphonie
+(http://prs.net/cgi-bin/n.cgi/acb/1/gmb5m1.mid)
+ Rimsky-Korsakov's "Flight of the Bumblebee" (very lazy to see it playing)
+(http://prs.net/cgi-bin/n.cgi/acb/7/bumble.mid)
The result looks as if a musician could play this. One restriction: "noteedit" does
still not recognize the
correct key signature. This will be. So long you can try to insert the key signature.
Other Properties
=================
* insertion/deletion/modification of notes, rests, dotted notes, slured
notes, clefs (with/without octave shift), time signatures, key signatures, beamed
notes, triplets on different staffs;
* building accords, undo, block copy, block delete,multi staff block copy,
multi staff block delete;
* program (instrument) change
* playing on /dev/sequencer (if correctly configured) whereby:
o giving each staff a different voice;
o giving each staff a different channel;
o highlighting the played notes;
o setting midi tempo;
* export MusiXTeX
* export Midi
* saving an restoring the files. The file format is similarily to the
format of the music publication program (MUP):
http://www.arkkra.com
So you if you are a MUP user you have the possibility to convert
the files into Midi and Postscript.
Because it is a Qt program I plan to transform it into a KDE
application (if ther is enough interest).
Planned
=======
*transpose
*mute
Conditions
==========
The program is tested on S.u.S.E.-Linux 6.2, Qt-2.0.2-13, and sound card
AWE-64. I used egcs-2.91.66.
You need the following packages:
* g++ compiler
* X11 (include and libraries)
* Qt-2 (include and libraries)
* the TSE3 library version 0.0.3 (a powerful sequencer library by Pete Goodliffe
<[EMAIL PROTECTED]>)
likewise:
* LibKMid; see http://www.arrakis.es/~rlarrosa/libkmid.html
(not all features are available in this case)
You can compile the program without any library. But in this case an
#include /usr/src/linux/include/linux/soundcard.h
occurs which can cause a lot of machine/sound card depencies. Therefore if
your sound doesn't work and you are sure Midi works on your machine (you use
KMid successfully) then try compilation one of the library.
--
J.Anders, Chemnitz, GERMANY ([EMAIL PROTECTED])
------------------------------
From: Andreas Kahari <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.questions,comp.os.linux.misc
Subject: Re: PS Editor?
Date: Wed, 31 May 2000 18:17:29 GMT
In article <[EMAIL PROTECTED]>,
NDQ <[EMAIL PROTECTED]> wrote:
> Juho Snellman wrote:
> > pstoedit can convert most PostScript files into formats editable
> > with most of the vector drawing packages available on Linux.
> > You can then edit the output in (for example) Xfig or Sketch,
> > and export back to PostScript.
>
> Where one can found "pstoedit" for Linux ?
>
> Thanks,
> Q.
>
DEB-file (for Debian):
http://www.debian.org/Packages/stable/graphics/pstoedit.html
Official home page?:
http://www.geocities.com/SiliconValley/Network/1958/pstoedit/
Use the search engine of your choice.
/A
--
# Andreas Kähäri, <URL:http://hello.to/andkaha/>.
# All junk e-mail is reported to the
# appropriate authorities, no exceptions.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Code improvements in timing loops?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 31 May 2000 18:41:50 GMT
On Wed, 31 May 2000 10:35:04 -0700, fprintf
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, "Robichaud,
>Jean-Philippe [BAN:6S33:EXCH]" <[EMAIL PROTECTED]>
>wrote:
>>Here is a little change that will do a little difference,
>saving you
>>couple cycles. Rewriting the entire procedure in C is a good
>idea. I
>>also suggest that you write a simpler/much faster version of
>>gettimeofday because you don't really need the time of the day,
>you need
>>difference between 2 time points and that is different.
>
>Ok, I know that it takes at least 22 microseconds on my 486 for
>a call to gettimeofday(), and I have to do it at least 4 times
>each time a car is overhead one or more of the sensors. So this
>could be where I am getting a little slow down. However, can
>you suggest a place where I can get some code for my own,
>quicker, timing loops? I am only using gettimeofday() because
>it is the place where I can access microseconds.
Just because struct timeval has a microseconds fields doesn't mean that it's
precise to the microsecond!
Your 486 doesn't have the clock register in it which would allow gettimeofday
to actually have a better precision than the clock tick counter in the kernel.
You are wasting time by calling it more than once in the same block of code,
since it's only good to 10 milliseconds anyway.
Pentiums have a the ``rtdsc'' instruction to read the time stamp counter.
However, it's still a waste to make a system call to sample the clock more than
once in what is otherwise a brief computation. It takes more time to call
gettimeofday() than to execute the code in between the calls.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.system,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 31 May 2000 13:53:50 -0500
In article <[EMAIL PROTECTED]>,
Yarick Rastrigin <[EMAIL PROTECTED]> wrote:
>>
>> Certainly. Just rebuild the db at 3am when the system is idle
>> and the end user is asleep...
>I for myself always hate this behavior. It's not uncommon in our company
>to work through
>the night, and updatedb slowing things down usually in the middle of
>hard debugging session
>pisses me off. And when it runs throuhg network mounts with 20 to 100
>Gb's SMB-mounted disks
>all across our local network - it's waay too long to complete, so it's
>better to
>killall find.
Updatedb should be configured to ignore network mounts by default.
Not all distributions/versions got that right.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Terje Tverberg <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.questions,comp.os.linux.misc,comp.lang.postscript
Subject: Re: PS Editor?
Date: 31 May 2000 21:23:47 +0200
NDQ <[EMAIL PROTECTED]> writes:
> Where one can found "pstoedit" for Linux ?
<URL: http://www.geocities.com/SiliconValley/Network/1958/pstoedit/>
There's also ps-mode.el, a PostScript editing mode for Emacs, available
from the Emacs Lisp List [1]:
<URL: http://anc.ed.ac.uk/~stephen/emacs/ell.html>
Terje
Footnotes:
[1] Search for ps-mode.el; you'll find to links, of which only the first
one is working (Peter Kleiweg's)
------------------------------
From: Roland <[EMAIL PROTECTED]>
Subject: Re: Threads or process?
Date: Wed, 31 May 2000 20:54:52 +0200
[EMAIL PROTECTED] wrote:
>
Hi!
> The context switching costs for threads is along the same lines as processes
> in Linux, because they share implementation. Other Unix systems could be
> quite different.
I assumed POSIX-Threads.
> | processes have own memory, threads not
> Each thread's stack space is separate, hence the automatic space in C/C++
> is likewise separate.
Hmmm. I dont really agree, cuz u can access a global var from every
thread.
U have to synchronize the access of course, but this is really necessary
if u have a tree or a similar adt. In this case, the performance of
threads is really better than that of procs. Maybe procs can be nearly
similar with shared memory.
> | when u have to processes, and one dies, the other dont car.
> | If u kill a process that has threads running, all threads die.
> | Communication between processes is very complicated, compared to threads
> | communication and synchronisation.
>
> I find communication between processes quite simple and straightforward.
I did not say it is NOT straightforward, but thread-com is more
convenient.
> | Generally: threads are pretty perfomant, compared to proccesses and they
> | are very cool to communicate with each other threads.
>
> What is perfomant?
Agreed, depends on application and user demands. Philosopic question.
Roland.
--
=====================================================
Roland Schaffer
[EMAIL PROTECTED]
http://www.bitsmart.com/roland_schaffer
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.apps) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-Apps Digest
******************************
