El dom, 01-04-2007 a las 11:07 -0400, Matthias Clasen escribió:
On 3/29/07, Federico Mena Quintero [EMAIL PROTECTED] wrote:
/desktop/gnome/thumbnailers/mime-type/mem-limit = xxx
But the thumbnailers don't get to set the gconf keys...
Huh? When a thumbnailer installs itself, it defines
On 4/2/07, Federico Mena Quintero [EMAIL PROTECTED] wrote:
But the thumbnailers don't get to set the gconf keys...
Huh? When a thumbnailer installs itself, it defines
/desktop/gnome/thumbnailers/mime-type/command
/desktop/gnome/thumbnailers/mime-type/enable
So it could define the
On 3/29/07, Federico Mena Quintero [EMAIL PROTECTED] wrote:
El mié, 28-03-2007 a las 21:29 +0200, Vincent Untz escribió:
What about putting limits that look sane in the library, but make it
possible for the thumbnailer to change those limits?
Like
El mié, 28-03-2007 a las 21:29 +0200, Vincent Untz escribió:
What about putting limits that look sane in the library, but make it
possible for the thumbnailer to change those limits?
Like
/desktop/gnome/thumbnailers/mime-type/mem-limit = xxx
?
I fear that this will lead to thumbnailers
On Tue, 2007-03-27 at 17:13 -0600, Hans Petter Jansson wrote:
I tend to favor read() on user data:
- For robustness: An mmap() map can become invalid if the file is
truncated, crashing the process.
Furthermore, read() handles errors (like say a disk i/o error) much more
gracefully.
El mié, 28-03-2007 a las 01:11 +0100, Bastien Nocera escribió:
I'll note that even if it doesn't do anything, modifying the
thumbnailers to not mmap the files they're trying to thumbnail goes
against your original point of the thumbnailers being third-party
applications we had no control
Le mercredi 28 mars 2007, à 11:20, Federico Mena Quintero a écrit :
Another option is to add a GConf key for the limits. Right now we
have /desktop/gnome/thumbnailers/mimetype/{command,enable}. We could
add cpu_limit and mem_limit under /thumbnailers. This is probably
overkill, but it would
On 1/9/07, Danilo Šegan [EMAIL PROTECTED] wrote:
Now we're getting to an interesting I18N point (and you should take
into account that I am in no way NLP expert): how do these stemmers cope
with languages other than English?
Used a very simple document in bn_IN for tracker search and t-s-t
El mar, 27-03-2007 a las 00:54 +0100, Bastien Nocera escribió:
I implemented your code some time ago in Totem's unstable branch, and I
was wondering why movies weren't getting thumbnailed anymore. I couldn't
mmap files larger than 256 megs.
[snip]
FYI, I've modified Totem's code to take
On mar, 2007-03-27 at 14:52 -0600, Federico Mena Quintero wrote:
[/me wonders if thumbnailers are measurably faster by using mmap()
instead of read()...]
It depends on their access pattern. If they need sequential access,
read() is better because it can do prefetching (readahead).
[Can you
On Wed, 2007-03-28 at 00:28 +0200, Xavier Bestel wrote:
On mar, 2007-03-27 at 14:52 -0600, Federico Mena Quintero wrote:
[/me wonders if thumbnailers are measurably faster by using mmap()
instead of read()...]
It depends on their access pattern. If they need sequential access,
read() is
On Mon, 2007-03-26 at 17:42 -0600, Hans Petter Jansson wrote:
On Tue, 2007-03-27 at 00:32 +0100, Bastien Nocera wrote:
On Mon, 2007-01-15 at 19:02 -0600, Federico Mena Quintero wrote:
The right fix is to put this in libgnomeui/gnome-thumbnail.c, so that
all thumbnailers get the same
On Tue, 2007-03-27 at 14:52 -0600, Federico Mena Quintero wrote:
El mar, 27-03-2007 a las 00:54 +0100, Bastien Nocera escribió:
I implemented your code some time ago in Totem's unstable branch, and I
was wondering why movies weren't getting thumbnailed anymore. I couldn't
mmap files
Le mardi 27 mars 2007 à 17:13 -0600, Hans Petter Jansson a écrit :
On Wed, 2007-03-28 at 00:28 +0200, Xavier Bestel wrote:
On mar, 2007-03-27 at 14:52 -0600, Federico Mena Quintero wrote:
[/me wonders if thumbnailers are measurably faster by using mmap()
instead of read()...]
It
Hey Federico,
On Mon, 2007-01-15 at 19:02 -0600, Federico Mena Quintero wrote:
El lun, 15-01-2007 a las 16:31 +, Bastien Nocera escribió:
On Mon, 2007-01-15 at 10:15 -0600, Federico Mena Quintero wrote:
snip
We put a call to setrlimit() in gst-office-thumbnailer, so that the
helper
On Tue, 2007-03-27 at 00:32 +0100, Bastien Nocera wrote:
On Mon, 2007-01-15 at 19:02 -0600, Federico Mena Quintero wrote:
The right fix is to put this in libgnomeui/gnome-thumbnail.c, so that
all thumbnailers get the same treatment. We just did this for
gsf-office-thumbnailer because it
On Tue, 2007-03-27 at 00:32 +0100, Bastien Nocera wrote:
Hey Federico,
On Mon, 2007-01-15 at 19:02 -0600, Federico Mena Quintero wrote:
El lun, 15-01-2007 a las 16:31 +, Bastien Nocera escribió:
On Mon, 2007-01-15 at 10:15 -0600, Federico Mena Quintero wrote:
snip
We put a call
El mar, 16-01-2007 a las 11:05 +, Bastien Nocera escribió:
On Mon, 2007-01-15 at 19:02 -0600, Federico Mena Quintero wrote:
The right fix is to put this in libgnomeui/gnome-thumbnail.c, so that
all thumbnailers get the same treatment. We just did this for
gsf-office-thumbnailer because
You might also consider checking if power is plugged in state for
laptops. So if they are plugged in it can probably do more IO and CPU
intensive operations. Great original idea though.
sri
On Fri, 2007-01-12 at 13:45 +, Jamie McCracken wrote:
Gustavo J. A. M. Carneiro wrote:
IMHO,
On Mon, 2007-01-15 at 19:02 -0600, Federico Mena Quintero wrote:
El lun, 15-01-2007 a las 16:31 +, Bastien Nocera escribió:
On Mon, 2007-01-15 at 10:15 -0600, Federico Mena Quintero wrote:
snip
We put a call to setrlimit() in gst-office-thumbnailer, so that the
helper convert(1)
On 1/15/07, Bastien Nocera [EMAIL PROTECTED] wrote:
On Mon, 2007-01-15 at 10:15 -0600, Federico Mena Quintero wrote:
snip
We put a call to setrlimit() in gst-office-thumbnailer, so that the
helper convert(1) process is limited to 256 MB of memory and 5 seconds
of CPU time. Some files do
El lun, 15-01-2007 a las 16:31 +, Bastien Nocera escribió:
On Mon, 2007-01-15 at 10:15 -0600, Federico Mena Quintero wrote:
snip
We put a call to setrlimit() in gst-office-thumbnailer, so that the
helper convert(1) process is limited to 256 MB of memory and 5 seconds
of CPU time. Some
2007/1/12, Gustavo J. A. M. Carneiro [EMAIL PROTECTED]:
Having tried tracker 0.5.3 for a couple of days what I have to say is:
1. it uses little memory;
2. it requires _a lot_ of CPU power.
Basically point 2 is a killer. No one is going to want to run this
except in servers.
Adam Schreiber wrote:
On 1/12/07, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote:
Basically point 2 is a killer. No one is going to want to run this
except in servers. Keeping the CPU busy almost 100% of the time is not
nice: consumes more power, gets my computer fan running faster and
On Fri, 2007-01-12 at 14:21 +, Jamie McCracken wrote:
thanks thats a good idea (I assume I can use dbus to get the info so
dont have to depend on any gnome stuff)
Yes. You can either get the AC power info from HAL (if you want to play
with all the devices and changed signals manually)
Hi,
Jamie McCracken wrote:
point 2 is scheduled at nice +19 (same with Ionice +7) so it only uses
more cpu if its idle.
That's not quite how the nice level works, at least in Linux. Higher
nice values get a shorter timeslice, so they merely have less time to
get their work in before other
Joe Shaw wrote:
Hi,
Jamie McCracken wrote:
point 2 is scheduled at nice +19 (same with Ionice +7) so it only uses
more cpu if its idle.
That's not quite how the nice level works, at least in Linux. Higher
nice values get a shorter timeslice, so they merely have less time to
get
Hi,
On Fri, 2007-01-12 at 12:04 +, Gustavo J. A. M. Carneiro wrote:
2. it requires _a lot_ of CPU power.
Basically point 2 is a killer. No one is going to want to run this
except in servers. Keeping the CPU busy almost 100% of the time is not
nice: consumes more power, gets my
On 1/12/07, Jamie McCracken [EMAIL PROTECTED] wrote:
Im open to people's thoughts on this... (IE is 100% cpu usage at
nice+19/ionice+7 during indexing really a problem?)
Having tracker use 100% CPU while the computer is on my lap kinda
sucks. Well, actually it blows. Lots of hot air on my leg.
People got excited by Bonobo 6 years ago, I know I did. We looked for
all sorts of places Bonobo could be used and we made them use Bonobo
even when Bonobo wasn't in any way the best solution. We are now
suffering for that excitement.
This is the second time the bonobo comparison has been
On 1/11/07, John Stowers [EMAIL PROTECTED] wrote:
This is the second time the bonobo comparison has been made.
Developers got excited about bonobo - users thought they were monkeys.
What we have here is a HEAP of excited users screaming for desktop
search. I dont think the two situations can
2007/1/11, Iain * [EMAIL PROTECTED]:
On 1/11/07, John Stowers [EMAIL PROTECTED] wrote:
This is the second time the bonobo comparison has been made.
Developers got excited about bonobo - users thought they were monkeys.
What we have here is a HEAP of excited users screaming for desktop
Hi Mikkel,
Le jeudi 11 janvier 2007, à 14:11, Mikkel Kamstrup Erlandsen a écrit :
We have started a project called Wasabi whose goal is to come up with
cross platform specs and apis regarding desktop search and metadata
storage (two different but related goals).
Our work is still in flux so
On Thu, 2007-01-11 at 10:55 +, Iain * wrote:
On 1/11/07, John Stowers [EMAIL PROTECTED] wrote:
This is the second time the bonobo comparison has been made.
Developers got excited about bonobo - users thought they were monkeys.
What we have here is a HEAP of excited users screaming
2007-01-08 klockan 19:49 skrev Emmanuele Bassi:
I have strong objections to the inclusion of tracker into GNOME 2.18.
That's my (strong) opinion as well. Thanks for making my voice heard,
Emmanuele :)
mvrgr, Wouter
--
:wq mail [EMAIL
Tracker has been a fantastic replacement for Beagle (slow, hard to
install, does not work on Reiser4, buggy, memory hug, etc) for me. I
don't understand why Tracker's maintainer fail to advertise it as an
alternative for people who have issues with Beagle. Because from the
user's perspective,
ons, 10 01 2007 kl. 10:36 +0530, skrev Ritesh Khadgaray:
On Mon, 2007-01-08 at 20:26 +, Richard Hughes wrote:
Grab some high-up redhat, suse, ubuntu distro people and ask them why
they ship beagle by default and not tracker. If you can come up with a
convincing argument, and one of the
Iain * wrote:
On 1/8/07, Vincent Untz [EMAIL PROTECTED] wrote:
Information about tracker:
http://www.gnome.org/projects/tracker/
I object to tracker not on any technical merits, but as a project I
don't think we have a concrete idea of what we want to use it for, I
feel that its getting
Hi,
On Mon, 2007-01-08 at 20:47 +0100, Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only index
metadata and/or contents. It can also be used a stand alone metadata DB
so I think tracker should be flexible enough for most
Joe Shaw wrote:
Hi,
On Mon, 2007-01-08 at 20:47 +0100, Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only index
metadata and/or contents. It can also be used a stand alone metadata DB
so I think tracker should be flexible
Hi,
On Wed, 2007-01-10 at 16:26 +, Jamie McCracken wrote:
Joe Shaw wrote:
[snipped my concerns about Tracker]
all these also apply to EDS too yet no one complains?
Some of them apply. EDS isn't a general data store; it has APIs and
backends that are very specific to the types of data it
Joe Shaw wrote:
Hi,
On Wed, 2007-01-10 at 16:26 +, Jamie McCracken wrote:
Joe Shaw wrote:
[snipped my concerns about Tracker]
all these also apply to EDS too yet no one complains?
Some of them apply. EDS isn't a general data store; it has APIs and
backends that are very specific to
On Wed, 2007-01-10 at 17:53 +, Andrew Sobala wrote:
The opensync guys valiantly attempt to be an EDS producer.
(The tone is due to opensync never having succeeded in syncing any of my
portable devices!)
I've seen OpenSync actually synchronise from Google Calendar to
Evolution, so
Joe Shaw wrote:
Hi,
On Wed, 2007-01-10 at 16:26 +, Jamie McCracken wrote:
Joe Shaw wrote:
[snipped my concerns about Tracker]
all these also apply to EDS too yet no one complains?
Some of them apply. EDS isn't a general data store; it has APIs and
backends that are very specific to
On 1/10/07, Joe Shaw [EMAIL PROTECTED] wrote:
Some of them apply. EDS isn't a general data store; it has APIs and
backends that are very specific to the types of data it stores. Also,
very few applications (none other than Evolution, I believe) actually
store info in EDS. They're all read
Dennis Cranston wrote:
Tracker is a great project, and gnome-search-tool should eventually be
replaced by something
faster and more useful. Yet, my personal opinion is that tracker-search-tool
is not polished
enough for prime time. Although it does a good job searching by filename and
Hi,
On Wed, 10 Jan 2007 18:11:16 +0100, Andr? R?diger wrote:
1. Identify candidates that could use the tracker features. I think of
[..]
I just want to fully support this point. Tracker (or beagle, or whatever)
sounds great. Let's use it. Then, when it's useful, let's include it.
Think of it
On 1/10/07, Jamie McCracken [EMAIL PROTECTED] wrote:
Iain * wrote:
On 1/10/07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
I bet that the Epiphany developers does not think it is worth their
time if Tracker doesn't get included in GNOME...
Then how will we know if Tracker is what we
Ronald S. Bultje wrote:
Hi,
On Wed, 10 Jan 2007 18:11:16 +0100, Andr? R?diger wrote:
1. Identify candidates that could use the tracker features. I think of
[..]
I just want to fully support this point. Tracker (or beagle, or whatever)
sounds great. Let's use it. Then, when it's useful,
Hi,
On Wed, 2007-01-10 at 18:22 +, Jamie McCracken wrote:
Tagging in fspot does not use leaftag afaik.
It doesn't, no. F-Spot predates Leaftag by several years.
Their metadata system appears to be based around something
called semweb.
SemWeb is an RDF library. Tags are stored
Joe Shaw wrote:
Hi,
On Mon, 2007-01-08 at 20:47 +0100, Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only index
metadata and/or contents. It can also be used a stand alone metadata DB
so I think tracker should be flexible
Emmanuele Bassi wrote:
On Mon, 2007-01-08 at 19:33 +0100, Vincent Untz wrote:
Information about tracker:
http://www.gnome.org/projects/tracker/
okay, I'll bite.
+++
ouch !
I have strong objections to the inclusion of tracker into GNOME 2.18.
Actually, I have one strong objection,
Ross Burton wrote:
On Mon, 2007-01-08 at 18:49 +, Emmanuele Bassi wrote:
I have strong objections to the inclusion of tracker into GNOME 2.18.
Seconded.
[snip]
Yeah, those were what I wanted to say too.
so, in short, I'd wait *at least* until the next development cycle to
even
On Mon, 2007-01-08 at 19:27 +, Jamie McCracken wrote:
tracker is now in fedora and I have a Debian Developer putting it
into
debain and ubuntu so if distro inclusion is a good guide (which you
asserted to last time) then why should it not be suitable for
inclusion
in gnome at this
Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only
index metadata and/or contents. It can also be used a stand alone
metadata DB so I think tracker should be flexible enough for most
cases where you only want a subset of its
+1
I have strong objections to the inclusion of tracker into GNOME 2.18.
Actually, I have one strong objection, that is: what's proposed for
inclusion and where? If it's tracker-search-tool (the UI), I'd say that
for what tracker *does* right now, there's no difference between tracker
and
I don't think you have to be a blessed dependency to get excited over
new functionality, or to add it as an optional support via #ifdef to
other software. gnome-power-manager was being shipped in 90% of the
GNOME distros by default before it was accepted into the desktop set.
I agree, but
quote who=Emmanuele Bassi
I have strong objections to the inclusion of tracker into GNOME 2.18.
I would like someone to coherently explain what tracker is before I could
seriously consider supporting it for inclusion.
- Jeff
--
linux.conf.au 2007: Sydney, Australia
hi Jamie;
no need to Cc: me - I'm on the list.
On Mon, 2007-01-08 at 19:13 +, Jamie McCracken wrote:
Emmanuele Bassi wrote:
On Mon, 2007-01-08 at 19:33 +0100, Vincent Untz wrote:
Information about tracker:
http://www.gnome.org/projects/tracker/
okay, I'll bite.
+++
ouch !
59 matches
Mail list logo
