$ port search fortran No match for fortran found $ port search g95 g95 lang/g95 0.90 Another GNU Fortran 95 compiler the same with "latex", "editor" and much more wouldn't it be better to make "search" actually searching thoughout descriptions too?
Le 20 sept. 07 à 20:44, Mij a écrit :
$ port search fortran No match for fortran found
$ port search g95 g95 lang/g95 0.90 Another GNU Fortran 95 compiler
the same with "latex", "editor" and much more
wouldn't it be better to make "search" actually searching thoughout descriptions too?
Just use `port search description:fortran`. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On 21/set/07, at 08:00, N_Ox wrote:
Le 20 sept. 07 à 20:44, Mij a écrit :
wouldn't it be better to make "search" actually searching thoughout descriptions too?
Just use `port search description:fortran`.
Automatically searching in the name AND description would be more handy, consistent with other package managers and intuitive. If one want to search the name alone, it can use "search name:" instead. JM2C
Le 21 sept. 07 à 12:34, Mij a écrit :
On 21/set/07, at 08:00, N_Ox wrote:
Le 20 sept. 07 à 20:44, Mij a écrit :
wouldn't it be better to make "search" actually searching thoughout descriptions too?
Just use `port search description:fortran`.
Automatically searching in the name AND description would be more handy, consistent with other package managers and intuitive.
If one want to search the name alone, it can use "search name:" instead.
JM2C
I don't find it consistent with other package managers (at least not Fink, Portage or pkgsrc), neither than more intuitive. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On 21/set/07, at 18:31, N_Ox wrote:
Le 21 sept. 07 à 12:34, Mij a écrit :
On 21/set/07, at 08:00, N_Ox wrote:
Le 20 sept. 07 à 20:44, Mij a écrit :
wouldn't it be better to make "search" actually searching thoughout descriptions too?
Just use `port search description:fortran`.
Automatically searching in the name AND description would be more handy, consistent with other package managers and intuitive.
If one want to search the name alone, it can use "search name:" instead.
JM2C
I don't find it consistent with other package managers (at least not Fink, Portage or pkgsrc)
Some examples doing so: APT - the first and sometimes told the best -ever package manager yum - redhat's one ports (I don't know more) fink also does. Besides all, it all depends to what you want to be inspired. Portage is what most people argue is the reason why the "Gentoo wave" weakened in favour to Ubuntu. Pkgsrc has a very restricted userbase so they probably haven't a strong feedback about usability topics.
neither than more intuitive.
you usually prefer to issue one search, get a list of some results that you walk and ignore the ones you're not interested in, better than not finding what you wanted to, and need to issue another command to find the rest to be sure. And, as if you're coming from one package manager you're most probably coming from one between APT, yum or ports, you could expect that the search is in name AND description, and give up when you see that searching for "editor" has no results and erroneously conclude that macports portbase is still poor. Anyway, try to make a balanced comparison and take your choice. bye
Le 22 sept. 07 à 12:30, Mij a écrit :
On 21/set/07, at 18:31, N_Ox wrote:
Le 21 sept. 07 à 12:34, Mij a écrit :
On 21/set/07, at 08:00, N_Ox wrote:
Le 20 sept. 07 à 20:44, Mij a écrit :
wouldn't it be better to make "search" actually searching thoughout descriptions too?
Just use `port search description:fortran`.
Automatically searching in the name AND description would be more handy, consistent with other package managers and intuitive.
If one want to search the name alone, it can use "search name:" instead.
JM2C
I don't find it consistent with other package managers (at least not Fink, Portage or pkgsrc)
Some examples doing so: APT - the first and sometimes told the best -ever package manager yum - redhat's one ports (I don't know more)
fink also does.
Besides all, it all depends to what you want to be inspired. Portage is what most people argue is the reason why the "Gentoo wave" weakened in favour to Ubuntu. Pkgsrc has a very restricted userbase so they probably haven't a strong feedback about usability topics.
Fink does not, fink gives user two different commands to achieve name and name + description search. Concerning Portage, it's my "best -ever package manager", and i would like some features of it being ported to MacPorts (who said slots?).
neither than more intuitive.
you usually prefer to issue one search, get a list of some results that you walk and ignore the ones you're not interested in, better than not finding what you wanted to, and need to issue another command to find the rest to be sure.
And, as if you're coming from one package manager you're most probably coming from one between APT, yum or ports, you could expect that the search is in name AND description, and give up when you see that searching for "editor" has no results and erroneously conclude that macports portbase is still poor.
Search for editor inside description is no good anyway, you would rather do `port search category:editors`
Anyway, try to make a balanced comparison and take your choice.
bye
IMHO The only thing we need is better documentation, and this problem will soon disappear. Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
It is possible to use Pallet to search the port tree by name, description, category all at once. Pallet can be installed via MacPorts and is still pre-alpha, so the searching is about all its good for at this point. On 22 Sep 2007, at 08:48, N_Ox wrote:
Le 22 sept. 07 à 12:30, Mij a écrit :
On 21/set/07, at 18:31, N_Ox wrote:
Le 21 sept. 07 à 12:34, Mij a écrit :
On 21/set/07, at 08:00, N_Ox wrote:
Le 20 sept. 07 à 20:44, Mij a écrit :
wouldn't it be better to make "search" actually searching thoughout descriptions too?
Just use `port search description:fortran`.
Automatically searching in the name AND description would be more handy, consistent with other package managers and intuitive.
If one want to search the name alone, it can use "search name:" instead.
JM2C
I don't find it consistent with other package managers (at least not Fink, Portage or pkgsrc)
Some examples doing so: APT - the first and sometimes told the best -ever package manager yum - redhat's one ports (I don't know more)
fink also does.
Besides all, it all depends to what you want to be inspired. Portage is what most people argue is the reason why the "Gentoo wave" weakened in favour to Ubuntu. Pkgsrc has a very restricted userbase so they probably haven't a strong feedback about usability topics.
Fink does not, fink gives user two different commands to achieve name and name + description search. Concerning Portage, it's my "best -ever package manager", and i would like some features of it being ported to MacPorts (who said slots?).
neither than more intuitive.
you usually prefer to issue one search, get a list of some results that you walk and ignore the ones you're not interested in, better than not finding what you wanted to, and need to issue another command to find the rest to be sure.
And, as if you're coming from one package manager you're most probably coming from one between APT, yum or ports, you could expect that the search is in name AND description, and give up when you see that searching for "editor" has no results and erroneously conclude that macports portbase is still poor.
Search for editor inside description is no good anyway, you would rather do `port search category:editors`
Anyway, try to make a balanced comparison and take your choice.
bye
IMHO The only thing we need is better documentation, and this problem will soon disappear.
Regards,
-- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Randall Wood wrote:
It is possible to use Pallet to search the port tree by name, description, category all at once.
Pallet can be installed via MacPorts and is still pre-alpha, so the searching is about all its good for at this point.
PortAuthority can also search ports by name and category. It used to rely on the "port search" mechanism, but now uses its own algorithm which is faster. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
On Sep 22, 2007, at 09:46, Kevin Walzer wrote:
Randall Wood wrote:
It is possible to use Pallet to search the port tree by name, description, category all at once. Pallet can be installed via MacPorts and is still pre-alpha, so the searching is about all its good for at this point.
PortAuthority can also search ports by name and category. It used to rely on the "port search" mechanism, but now uses its own algorithm which is faster.
So.... it sounds like people want this feature, so.... it sounds like it should be put into base, rather than having each GUI have to reimplement it. And if "port search" was too slow, and you came up with something faster, why don't we put that in base as well?
Le 23 sept. 07 à 19:08, Ryan Schmidt a écrit :
On Sep 22, 2007, at 09:46, Kevin Walzer wrote:
Randall Wood wrote:
It is possible to use Pallet to search the port tree by name, description, category all at once. Pallet can be installed via MacPorts and is still pre-alpha, so the searching is about all its good for at this point.
PortAuthority can also search ports by name and category. It used to rely on the "port search" mechanism, but now uses its own algorithm which is faster.
So.... it sounds like people want this feature, so.... it sounds like it should be put into base, rather than having each GUI have to reimplement it. And if "port search" was too slow, and you came up with something faster, why don't we put that in base as well?
PortAuthority is not free software, unfortunately. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
Ryan Schmidt wrote:
So.... it sounds like people want this feature, so.... it sounds like it should be put into base, rather than having each GUI have to reimplement it. And if "port search" was too slow, and you came up with something faster, why don't we put that in base as well?
PortAuthority's method works by running "port list" on startup, caching the data, then iterating through that when the user searches for a term. It's faster than "port search" only because it doesn't have to launch a new process of tclsh when the user searches for a term. This method make sense for a GUI because it reduces the number of times it has to call out to the command-line tool, but it doesn't represent any sort of improvement in the command-line tool itself. Imagine having port run "port list" every time it started up...the result would be slower, not faster. -- Kevin Walzer Code by Kevin http://www.codebykevin.com
I think all the GUIs cache most of the port data if only because they need to display it and display different views of it rapidly. There is no use for having the port command allocate something on the order of 5 megs of RAM and walk the tree just to run a faster search. The GUIs have the luxury of long training - users kind of expect it to take a little longer to start before running fast, while CLIs need to be fast and lean. On 23 Sep 2007, at 14:21, Kevin Walzer wrote:
Ryan Schmidt wrote:
So.... it sounds like people want this feature, so.... it sounds like it should be put into base, rather than having each GUI have to reimplement it. And if "port search" was too slow, and you came up with something faster, why don't we put that in base as well?
PortAuthority's method works by running "port list" on startup, caching the data, then iterating through that when the user searches for a term. It's faster than "port search" only because it doesn't have to launch a new process of tclsh when the user searches for a term. This method make sense for a GUI because it reduces the number of times it has to call out to the command-line tool, but it doesn't represent any sort of improvement in the command-line tool itself. Imagine having port run "port list" every time it started up...the result would be slower, not faster.
-- Kevin Walzer Code by Kevin http://www.codebykevin.com
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On Sep 23, 2007, at 14:50, Randall Wood wrote:
On 23 Sep 2007, at 14:21, Kevin Walzer wrote:
Ryan Schmidt wrote:
So.... it sounds like people want this feature, so.... it sounds like it should be put into base, rather than having each GUI have to reimplement it. And if "port search" was too slow, and you came up with something faster, why don't we put that in base as well?
PortAuthority's method works by running "port list" on startup, caching the data, then iterating through that when the user searches for a term. It's faster than "port search" only because it doesn't have to launch a new process of tclsh when the user searches for a term. This method make sense for a GUI because it reduces the number of times it has to call out to the command-line tool, but it doesn't represent any sort of improvement in the command-line tool itself. Imagine having port run "port list" every time it started up...the result would be slower, not faster.
I think all the GUIs cache most of the port data if only because they need to display it and display different views of it rapidly. There is no use for having the port command allocate something on the order of 5 megs of RAM and walk the tree just to run a faster search. The GUIs have the luxury of long training - users kind of expect it to take a little longer to start before running fast, while CLIs need to be fast and lean.
Understood! I agree -- that's a nice optimization for a GUI that won't work for a CLI. Oh well. :)
participants (5)
-
Kevin Walzer
-
Mij
-
N_Ox
-
Randall Wood
-
Ryan Schmidt