Discussion:
SoC
(too old to reply)
Duane Whitty
2007-05-13 04:06:51 UTC
Permalink
Garrett,

Sounds like you're involved in a cool project. What kind of
community collaboration/involvement would be helpful to you?

Once, a long, long time ago, I wrote quite a bit of bdb 1.85
code. At that time it WAS the current version :) I might
actually remember a bit if I start working with it again.
But what would be most useful to you?

And if I may ask about a design decision: Why did you choose
a hash structure? Perhaps if you have time you could give
a little more info but whatever fits your schedule.

Good luck on your project.

Duane
Garrett Cooper
2007-05-14 05:39:51 UTC
Permalink
Post by Duane Whitty
Garrett,
Sounds like you're involved in a cool project. What kind of
community collaboration/involvement would be helpful to you?
Once, a long, long time ago, I wrote quite a bit of bdb 1.85
code. At that time it WAS the current version :) I might
actually remember a bit if I start working with it again.
But what would be most useful to you?
And if I may ask about a design decision: Why did you choose
a hash structure? Perhaps if you have time you could give
a little more info but whatever fits your schedule.
Good luck on your project.
Duane
Duane,

I actually chose hash structure at the time because I thought it was
appropriate for the size of the ports tree and the number of files that
may need to be used. Plus, Kris suggested that :). Given the way that
I've seen how things are used, this would be great for searching for who
added what file, finding cyclic dependencies easily, maintaining
uniqueness, etc, many common issues with the current ruby scripts.

Also, the other available BDB options like btrees seem inefficient,
over the long run :(..

Do you know of any simple APIs that can quickly dump fields in use with
BDB .db files? I have a hunch given the Ruby that I've taken a look at
with Portupgrade that something very inefficient's in play, but I want
to test my assumption first before jumping to conclusions.

Thank you very much for the help :)!

-Garrett
Garrett Cooper
2007-05-14 06:08:30 UTC
Permalink
Garrett Cooper wrote:

<snip>
Post by Garrett Cooper
Do you know of any simple APIs that can quickly dump fields in use
with BDB .db files? I have a hunch given the Ruby that I've taken a look
at with Portupgrade that something very inefficient's in play, but I
want to test my assumption first before jumping to conclusions.
s/dump fields/dump field names/
Duane Whitty
2007-05-14 20:29:22 UTC
Permalink
Post by Garrett Cooper
Post by Duane Whitty
Garrett,
Sounds like you're involved in a cool project. What kind of
community collaboration/involvement would be helpful to you?
Once, a long, long time ago, I wrote quite a bit of bdb 1.85
code. At that time it WAS the current version :) I might
actually remember a bit if I start working with it again.
But what would be most useful to you?
And if I may ask about a design decision: Why did you choose
a hash structure? Perhaps if you have time you could give
a little more info but whatever fits your schedule.
Good luck on your project.
Duane
Duane,
I actually chose hash structure at the time because I thought it was
appropriate for the size of the ports tree and the number of files that
may need to be used. Plus, Kris suggested that :). Given the way that
I've seen how things are used, this would be great for searching for who
added what file, finding cyclic dependencies easily, maintaining
uniqueness, etc, many common issues with the current ruby scripts.
Also, the other available BDB options like btrees seem inefficient,
over the long run :(..
I guess frequent deletions and lack of space recovery are the problem with btrees?
Post by Garrett Cooper
Do you know of any simple APIs that can quickly dump fields in use
with BDB .db files? I have a hunch given the Ruby that I've taken a look at
with Portupgrade that something very inefficient's in play, but I want
to test my assumption first before jumping to conclusions.
I did a quick ports search and came up with databases/ruby-bdb1. I don't grok ruby
but I've telling myself I should learn [sigh]. I don't know if this has a simple
API or not; I'll take a look but I suspect it is probably overkill.

If this doesn't meet your project's needs I'll try coding something up in C. I
imagine we'll need some tools written in C at some point anyhow.
Post by Garrett Cooper
Thank you very much for the help :)!
Well, we'll see about how much help I can be; but I'll try. It's your project
so let me know what you need or don't need/want
Post by Garrett Cooper
-Garrett
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Duane Whitty
2007-05-15 03:50:16 UTC
Permalink
[snipped]
Post by Duane Whitty
Post by Garrett Cooper
Do you know of any simple APIs that can quickly dump fields in use
with BDB .db files? I have a hunch given the Ruby that I've taken a look at
with Portupgrade that something very inefficient's in play, but I want
to test my assumption first before jumping to conclusions.
I did a quick ports search and came up with databases/ruby-bdb1. I don't grok ruby
but I've telling myself I should learn [sigh]. I don't know if this has a simple
API or not; I'll take a look but I suspect it is probably overkill.
If this doesn't meet your project's needs I'll try coding something up in C. I
imagine we'll need some tools written in C at some point anyhow.
Post by Garrett Cooper
Thank you very much for the help :)!
Well, we'll see about how much help I can be; but I'll try. It's your project
so let me know what you need or don't need/want
Post by Garrett Cooper
-Garrett
Well, databases/ruby-bdb1 will not work because pkgtools uses the newer version of
DB, Sleepycat DB 4.(2|3) I guess. However there is ruby-bdb that seems like it
would be simple for someone who understands ruby. I've also noticed there is a
perl and a python interface available as well.

I wonder what the ramifications of the above are to the goal of using the bdb in
our base system to add db smarts to the pkg_install tools in a way that will be
complementary to exising tools?

Duane
Garrett Cooper
2007-05-15 04:42:18 UTC
Permalink
Post by Duane Whitty
[snipped]
Post by Duane Whitty
Post by Garrett Cooper
Do you know of any simple APIs that can quickly dump fields in use
with BDB .db files? I have a hunch given the Ruby that I've taken a look at
with Portupgrade that something very inefficient's in play, but I want
to test my assumption first before jumping to conclusions.
I did a quick ports search and came up with databases/ruby-bdb1. I don't grok ruby
but I've telling myself I should learn [sigh]. I don't know if this has a simple
API or not; I'll take a look but I suspect it is probably overkill.
If this doesn't meet your project's needs I'll try coding something up in C. I
imagine we'll need some tools written in C at some point anyhow.
Post by Garrett Cooper
Thank you very much for the help :)!
Well, we'll see about how much help I can be; but I'll try. It's your project
so let me know what you need or don't need/want
Post by Garrett Cooper
-Garrett
Well, databases/ruby-bdb1 will not work because pkgtools uses the newer version of
DB, Sleepycat DB 4.(2|3) I guess. However there is ruby-bdb that seems like it
would be simple for someone who understands ruby. I've also noticed there is a
perl and a python interface available as well.
I wonder what the ramifications of the above are to the goal of using the bdb in
our base system to add db smarts to the pkg_install tools in a way that will be
complementary to exising tools?
Duane
BDB-1 is an available option actually with the ruby tools. Try "make
config" in the ports-mgmt/portupgrade directory.

BDB v2+ isn't allowable in the base system because of licensing issues.
I already talked to Kris about it.

-Garrett
Garrett Cooper
2007-05-15 05:17:35 UTC
Permalink
Post by Duane Whitty
Post by Garrett Cooper
Post by Duane Whitty
Garrett,
Sounds like you're involved in a cool project. What kind of
community collaboration/involvement would be helpful to you?
Once, a long, long time ago, I wrote quite a bit of bdb 1.85
code. At that time it WAS the current version :) I might
actually remember a bit if I start working with it again.
But what would be most useful to you?
And if I may ask about a design decision: Why did you choose
a hash structure? Perhaps if you have time you could give
a little more info but whatever fits your schedule.
Good luck on your project.
Duane
Duane,
I actually chose hash structure at the time because I thought it was
appropriate for the size of the ports tree and the number of files that
may need to be used. Plus, Kris suggested that :). Given the way that
I've seen how things are used, this would be great for searching for who
added what file, finding cyclic dependencies easily, maintaining
uniqueness, etc, many common issues with the current ruby scripts.
Also, the other available BDB options like btrees seem inefficient,
over the long run :(..
I guess frequent deletions and lack of space recovery are the problem with btrees?
Yes, that's part of it, but having to pivot the damn tree every once in
a while to get good performance is a waste of resources too. Hash tables
are of course much better at insertion / deletion as you probably well
know. Having to do (possibly) O(n) insertion and deletion with btrees
isn't good at all :(.. On hash tables its O(c) to something less than
99.9% of the time from what I know O(n) (depends on the bucket and
generation schemes of course). All that has to happen every once in a
while is the buckets capacity may increase, or the number of overall
buckets to decrease collisions, but it seems much more feasible than a
lopsided tree :).
Post by Duane Whitty
Post by Garrett Cooper
Do you know of any simple APIs that can quickly dump fields in use
with BDB .db files? I have a hunch given the Ruby that I've taken a look at
with Portupgrade that something very inefficient's in play, but I want
to test my assumption first before jumping to conclusions.
I did a quick ports search and came up with databases/ruby-bdb1. I don't grok ruby
but I've telling myself I should learn [sigh]. I don't know if this has a simple
API or not; I'll take a look but I suspect it is probably overkill.
Ruby's nice, but it's built on Perl so I have suspicions on its overall
usability / speed given my experience with Perl over the past 4 months
daily for work :(.. Ruby's just the new big thing for programming
languages, so everyone's into it. Kind of like how Java was compared to
C/C++ a few years back. But once everything dies down people will
realize that they'll still have to program in C/C++/Perl for real-world
applications.

Python seems better than Ruby from what I can see, but I really don't
like the mandatory indentation thing. Ew..
Post by Duane Whitty
If this doesn't meet your project's needs I'll try coding something up in C. I
imagine we'll need some tools written in C at some point anyhow.
That's ok. If you don't know anything right offhand that's more than a
few lines, I'll keep on hunting / prodding for documentation /
resources, and/or keep on reading the /usr/src/lib/libc/db source. I was
just looking for something that could help me get moving quickly in the
right direction.
Post by Duane Whitty
Post by Garrett Cooper
Thank you very much for the help :)!
Well, we'll see about how much help I can be; but I'll try. It's your project
so let me know what you need or don't need/want
Thank you again though :). Having seasoned vets help will certainly
bring about good ideas and ideologies that I may not have thought of
myself, and will no doubt prove to foster better production code than I
could do by myself.

Cheers,
-Garrett
Duane Whitty
2007-05-15 06:54:15 UTC
Permalink
[snipped]
Post by Garrett Cooper
Post by Duane Whitty
I wonder what the ramifications of the above are to the goal of using the
bdb in
our base system to add db smarts to the pkg_install tools in a way that
will be
complementary to exising tools?
Duane
BDB-1 is an available option actually with the ruby tools. Try "make
config" in the ports-mgmt/portupgrade directory.
Excellent, I just checked. That's great. I was worried for about a
second :) I never thought to check that out, sure glad you did!

Duane

[more snipped]
Post by Garrett Cooper
-Garrett
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Tom Evans
2007-05-15 07:31:57 UTC
Permalink
Garrett Cooper
2007-05-15 08:08:03 UTC
Permalink
Post by Garrett Cooper
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its
overall usability / speed given my experience with Perl over the past
4 months daily for work :(.. Ruby's just the new big thing for
programming languages, so everyone's into it. Kind of like how Java
was compared to C/C++ a few years back. But once everything dies down
people will realize that they'll still have to program in C/C++/Perl
for real-world applications.
Python seems better than Ruby from what I can see, but I really don't
like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was what
I was trying to aim for.
Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.
-Garrett
Sorry for all you Java lovers out there.. it's just that from where I'm
at I don't see anyone using it in the workplace (Intel). We're all using
C/C++/Perl, with occasional spots of Ruby/Python.

-Garrett
Sean Bryant
2007-05-15 14:04:48 UTC
Permalink
Post by Garrett Cooper
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its
overall usability / speed given my experience with Perl over the
past 4 months daily for work :(.. Ruby's just the new big thing for
programming languages, so everyone's into it. Kind of like how Java
was compared to C/C++ a few years back. But once everything dies
down people will realize that they'll still have to program in
C/C++/Perl for real-world applications.
Python seems better than Ruby from what I can see, but I really
don't like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was
what I was trying to aim for.
Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.
-Garrett
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
Where did you find you need perl to build ruby. Its a separate thing all
together.
Garrett Cooper
2007-05-15 08:05:07 UTC
Permalink
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its overall
usability / speed given my experience with Perl over the past 4 months
daily for work :(.. Ruby's just the new big thing for programming
languages, so everyone's into it. Kind of like how Java was compared to
C/C++ a few years back. But once everything dies down people will
realize that they'll still have to program in C/C++/Perl for real-world
applications.
Python seems better than Ruby from what I can see, but I really don't
like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was what
I was trying to aim for.

Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.

-Garrett
Duane Whitty
2007-05-15 21:30:26 UTC
Permalink
Post by Garrett Cooper
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its overall
usability / speed given my experience with Perl over the past 4 months
daily for work :(.. Ruby's just the new big thing for programming
languages, so everyone's into it. Kind of like how Java was compared to
C/C++ a few years back. But once everything dies down people will
realize that they'll still have to program in C/C++/Perl for real-world
applications.
Python seems better than Ruby from what I can see, but I really don't
like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was what
I was trying to aim for.
Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.
-Garrett
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
None of this matters


My only point is that if you need something quick to explore the format of
pkgdb.db or INDEX.db you are pretty well assured of finding a tool you
can work with; Perl, Python, or Ruby. If these aren't sufficient use C.

The pkg_* tools are written in C so in C they will be modified; but no
harm in doing initial exploration and prototyping with something else.

Let's stay focused!

Duane
Garrett Cooper
2007-05-19 19:28:25 UTC
Permalink
Post by Garrett Cooper
Post by Duane Whitty
Post by Garrett Cooper
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its
overall usability / speed given my experience with Perl over the
past 4 months daily for work :(.. Ruby's just the new big thing for
programming languages, so everyone's into it. Kind of like how Java
was compared to C/C++ a few years back. But once everything dies
down people will realize that they'll still have to program in
C/C++/Perl for real-world applications.
Python seems better than Ruby from what I can see, but I really
don't like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was
what I was trying to aim for.
Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.
-Garrett
None of this matters
My only point is that if you need something quick to explore the format of
pkgdb.db or INDEX.db you are pretty well assured of finding a tool you
can work with; Perl, Python, or Ruby. If these aren't sufficient use C.
The pkg_* tools are written in C so in C they will be modified; but no
harm in doing initial exploration and prototyping with something else.
Let's stay focused!
Duane
Ok, finally dumped the full database. Will analyze closely later on
tonight.
Cheers,
-Garrett
PS If you installed ruby-bdb, simply running "make config" in the
ports-mgmt/portupgrade directory and selecting ruby-bdb1 won't do. You
have to go into databases/ruby-bdb, do make deinstall, then go to
databases/ruby-bdb1 and do make install, or something similar.
If you haven't seen my entry yet, and you're interested, I've posted my
analysis of the INDEX-*.db file at:
<http://blogs.freebsdish.org/gcooper/2007/05/19/behind-index-db>.
I'd like to really discuss the additional metadata that gets tacked
onto each database file, in particular, is it necessary, and is there a
better way to do that?
Also, the whole Ruby ports tools writing to the ports db consistently
instead of at exit is another item which probably should be discussed
too (someone brought this up earlier).
Thanks,
-Garrett
Rick C. Petty
2007-05-16 16:06:20 UTC
Permalink
Post by Garrett Cooper
Sorry for all you Java lovers out there.. it's just that from where I'm
at I don't see anyone using it in the workplace (Intel). We're all using
C/C++/Perl, with occasional spots of Ruby/Python.
We use Java almost exclusively (Oracle), although scattered bits of Python
and occasional C/C++ thru JNI.

Not to start a flame war, but I much prefer Java and I know a lot of other
corporations are using it as well (just do a search for "software engineer"
on any job site, and count the Java hits vs. C++).

Also, Java outperforms Python/Ruby/Perl on all string manipulations from
our extensive tests. However, my group likes the philosophies behind Ruby
and likes the rapid development of Python when we need a scripting
language.

Use the Right Tool for the problem; just because you like using a hammer
doesn't mean all screwdrivers are stupid.

-- Rick C. Petty
y***@u.washington.edu
2007-05-16 20:41:27 UTC
Permalink
Post by Rick C. Petty
Post by Garrett Cooper
Sorry for all you Java lovers out there.. it's just that from where I'm
at I don't see anyone using it in the workplace (Intel). We're all using
C/C++/Perl, with occasional spots of Ruby/Python.
We use Java almost exclusively (Oracle), although scattered bits of Python
and occasional C/C++ thru JNI.
Not to start a flame war, but I much prefer Java and I know a lot of other
corporations are using it as well (just do a search for "software engineer"
on any job site, and count the Java hits vs. C++).
Also, Java outperforms Python/Ruby/Perl on all string manipulations from
our extensive tests. However, my group likes the philosophies behind Ruby
and likes the rapid development of Python when we need a scripting
language.
Use the Right Tool for the problem; just because you like using a hammer
doesn't mean all screwdrivers are stupid.
-- Rick C. Petty
Ok, fair enough. But there's a lot of overhead involved with Java with their completely OOP view on programming.

Also, although I know that many database solutions companies (in particular Oracle and IBM), do like Java, it's not used in many other regions of the market from what I've seen (Apple, Intel, M$, many other companies that have openings in my school's resume databases). Most want C++, C#, and VB.NET (ew)... and maybe Javascript with AJAX support.

Also, since I deleted the original message by accident, I wanted to note that I found a BDB dump feature in MySQL's source, so I'm going to try and adapt that to my SoC project just for research purposes to dump out the table fields and see how Ruby messes with the data.

-Garrett

PS If you hated BDB and loved SQL, please note that some SQL engines use BDB for a database backend instead of MyISAM, INNODB, etc.
Dag-Erling Smørgrav
2007-05-17 07:28:15 UTC
Permalink
Post by y***@u.washington.edu
Ok, fair enough. But there's a lot of overhead involved with Java with
their completely OOP view on programming.
Not really. Performance issues with Java mostly stem from the virtual
machine, and a good JRE should eliminate most if not all of them.
Post by y***@u.washington.edu
Also, although I know that many database solutions companies (in
particular Oracle and IBM), do like Java, it's not used in many other
regions of the market from what I've seen (Apple, Intel, M$, many
other companies that have openings in my school's resume
databases). Most want C++, C#, and VB.NET (ew)... and maybe Javascript
with AJAX support.
Apple aren't interested in Java because they've had Objective C from day
one.

Microsoft aren't interested in Java because they were legally barred
from implementing it after trying to "embrace and extend" it, so they
went ahead and reinvented it, badly.
Post by y***@u.washington.edu
PS If you hated BDB and loved SQL, please note that some SQL engines
use BDB for a database backend instead of MyISAM, INNODB, etc.
Because BDB and SQL are orthogonal solutions for orthogonal problems.
BDB is a key-value store; SQL is a query language. The bit you're
missing in the middle - the bit I think most people really want when
they say they want SQL - is a relational database engine.

SQLite provides storage, a relational database engine, and a query
language (which happens to be SQL but might just as well been a custom
query language stripped of SQL's warts), and ACID. The only thing it
lacks is strong typing. Implementing strong typing and a better query
language on top of the SQLite storage and relational engine is left as
an exercise to the reader :)

DES
--
Dag-Erling Smørgrav - ***@des.no
y***@u.washington.edu
2007-05-16 22:48:33 UTC
Permalink
Post by y***@u.washington.edu
Ok, fair enough. But there's a lot of overhead involved with Java with
their completely OOP view on programming.
Agreed.
Post by y***@u.washington.edu
Also, although I know that many database solutions companies (in particular
Oracle and IBM), do like Java, it's not used in many other regions of the
market from what I've seen (Apple, Intel, M$, many other companies that
have openings in my school's resume databases). Most want C++, C#, and
VB.NET (ew)... and maybe Javascript with AJAX support.
From what I've seen, after filtering out VB and C#, the next top is Java.
I completely agree with you about "ew".. not a big fan of C-flat or VB.
=)
Post by y***@u.washington.edu
PS If you hated BDB and loved SQL, please note that some SQL engines use
BDB for a database backend instead of MyISAM, INNODB, etc.
I was aware that MySQL has a lot of backends, but most hosting sites that
give you mysql don't give you backend options-- it's MyISAM or die. :-/
Anyway, good luck with the BDB. Have you thought about looking at
dbopen(3) or dbm(3)? I'm sure you'll get more FreeBSD supporters if you
use something already shipping with the stock system.
-- Rick C. Petty
It (BDB 1.8.5) is already in the system under:

/usr/src/lib/libc/db :)

hash(3) and btree(3) have more details in manpage format.

I'm just using parts of the MySQL server for research purposes. Thankfully the BDB dump code can be separated from the rest of the code and built modularly =).

-Garrett
Garrett Cooper
2007-05-18 03:46:29 UTC
Permalink
Post by Duane Whitty
Post by Garrett Cooper
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its overall
usability / speed given my experience with Perl over the past 4 months
daily for work :(.. Ruby's just the new big thing for programming
languages, so everyone's into it. Kind of like how Java was compared to
C/C++ a few years back. But once everything dies down people will
realize that they'll still have to program in C/C++/Perl for real-world
applications.
Python seems better than Ruby from what I can see, but I really don't
like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was what
I was trying to aim for.
Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.
-Garrett
None of this matters
My only point is that if you need something quick to explore the format of
pkgdb.db or INDEX.db you are pretty well assured of finding a tool you
can work with; Perl, Python, or Ruby. If these aren't sufficient use C.
The pkg_* tools are written in C so in C they will be modified; but no
harm in doing initial exploration and prototyping with something else.
Let's stay focused!
Duane
Ok, finally dumped the full database. Will analyze closely later on tonight.

Cheers,
-Garrett

PS If you installed ruby-bdb, simply running "make config" in the
ports-mgmt/portupgrade directory and selecting ruby-bdb1 won't do. You
have to go into databases/ruby-bdb, do make deinstall, then go to
databases/ruby-bdb1 and do make install, or something similar.
Garrett Cooper
2007-05-20 23:15:56 UTC
Permalink
Post by Garrett Cooper
Post by Garrett Cooper
Post by Duane Whitty
Post by Garrett Cooper
Post by Garrett Cooper
Ruby's nice, but it's built on Perl so I have suspicions on its
overall usability / speed given my experience with Perl over the
past 4 months daily for work :(.. Ruby's just the new big thing
for programming languages, so everyone's into it. Kind of like how
Java was compared to C/C++ a few years back. But once everything
dies down people will realize that they'll still have to program
in C/C++/Perl for real-world applications.
Python seems better than Ruby from what I can see, but I really
don't like the mandatory indentation thing. Ew..
Rubies are better Perls. That's the only connection between the two. One
day, a Japanese programmer got fed up with Perl, and wrote a better
language (for varying meanings of better).
Its not based or built on Perl in any respect.
Python and Ruby both have the same targets; to speed development time
and increase programmer productivity.
But one must make a Perl before one can make a Ruby. Maybe that was
what I was trying to aim for.
Ruby's nice, but it seems like it's going to be a bit passe in a few
years like Java was for compilable / interpretable languages.
-Garrett
None of this matters
My only point is that if you need something quick to explore the format of
pkgdb.db or INDEX.db you are pretty well assured of finding a tool you
can work with; Perl, Python, or Ruby. If these aren't sufficient use C.
The pkg_* tools are written in C so in C they will be modified; but no
harm in doing initial exploration and prototyping with something else.
Let's stay focused!
Duane
Ok, finally dumped the full database. Will analyze closely later on tonight.
Cheers,
-Garrett
PS If you installed ruby-bdb, simply running "make config" in the
ports-mgmt/portupgrade directory and selecting ruby-bdb1 won't do. You
have to go into databases/ruby-bdb, do make deinstall, then go to
databases/ruby-bdb1 and do make install, or something similar.
If you haven't seen my entry yet, and you're interested, I've posted
<http://blogs.freebsdish.org/gcooper/2007/05/19/behind-index-db>.
I'd like to really discuss the additional metadata that gets tacked
onto each database file, in particular, is it necessary, and is there a
better way to do that?
Also, the whole Ruby ports tools writing to the ports db
consistently instead of at exit is another item which probably should be
discussed too (someone brought this up earlier).
Thanks,
-Garrett
Posted more results here:
<http://blogs.freebsdish.org/gcooper/2007/05/20/the-inefficiencies-of-pkgdbdb/>.
Needless to say, I'm not happy with Portupgrade.

-Garret

Loading...