Alf 0.9.1 Released

Ruby
1

Hi all!

I’m pleased to announce that alf 0.9.1 has been released and pushed
to rubygems.org! See changes below.

= Alf – Relational Algebra at your fingertips

Alf brings the relational algebra both in Shell and in Ruby. In Shell,
because
manipulating any relation-like data source should be as straightforward
as
a
one-liner. In Ruby, because I’ve never understood why programming
languages
provide data structures like arrays, hashes, sets, trees and graphs but
not
relations… Let’s stop the segregation :wink:

Changes:

0.9.1 / 2011.07.13

  • Enhancements (public APIs)

    • Added the in-memory Alf::Relation data structure and associated
      tooling.
      This allows using Alf in a object-oriented usual way, in addition to
      the
      functional DSL:

      Alf.lispy.evaluate {
  (join (restrict :suppliers, lambda{ status > 10 }), :cities)
}

      is equivalent to

      suppliers, cities = [...], [...]
suppliers.restrict(lambda{ status > 10 }).join(cities)

      see README about how to obtain suppliers and cities relations in the
      first
      place.

    • Summarize now accepts a --allbut option, to specify ‘by’ attributes
      from
      an
      exclusion perspective

    • .alf files are now evaluated in such a way that backtraces are
      “traceability
      friendly”

  • Non backward-compatible changes to public APIs

    • Lispy#with has been removed because not being stable enough. The
      clean
      way
      of reusing sub-queries is as follows (non purely functional, so far)

      kept_suppliers = (restrict :suppliers, lambda{ status > 10 })
with_countries = (join kept_suppliers, :cities)
supplying      = (join with_countries, :supplies)
(summarize supplying,
           [:country],
           :which => Agg::group(:pid),
           :total => Agg::sum{ qty })

    • As a consequence, named data sources (Symbols, like :suppliers
      above)
      are
      now resolved at compile time, which is less powerful, yet much
      simpler
      and
      sound.

    • Nest and Unnest have been renamed to Wrap and Unwrap respectively.
      This
      is
      to better conform to TUTORIAL D’s terminology.

    • Lispy#chain was kept public in 0.9.0 by error and has been entirely
      removed
      from the DSL.

  • Enhancements (internals)

    • Reader.reader delegates to Reader.coerce when its first argument is
      not
      a String. This allows calling Reader.reader(args.first || $stdin) in
      quickl
      commands for example.

    • Operator, Operator::Relational and Operator::NonRelational have a
      .each
      class method that yields operator classes

  • Bug fixes

    • Fixed a bug that led to an Nil error when using unary operators on
      $stdin
    • Fixed a bug when summarizing or sorting on Symbol attributes with
      ruby
      1.8
    • Fixed numerous crashes under rubinius

Have a nice day!!
Bernard

2

Bernard L. wrote in post #1010469:

0.9.1 / 2011.07.13

  • Non backward-compatible changes to public APIs

According to the RubyGems Rational Versioning Policy1, when a
release contains non-backward-compatible changes, its major version
number should be increased. So this release should really be 1.0.0!

Please be aware of this convention and help to spread it within the
Ruby community, because recently some high-profile libraries2 made
the same version numbering mistake and made trouble for their users.

Thanks for your consideration.

3

On Jul 13, 4:37pm, Suraj K. [email protected] wrote:

Ruby community, because recently some high-profile libraries[2] made
the same version numbering mistake and made trouble for their users.

Thanks for your consideration.

It’s not true for 0.x releases --in which case the second number
represents major changes.

4

On Wed, Jul 13, 2011 at 10:46 PM, Intransition [email protected]
wrote:

It’s not true for 0.x releases --in which case the second number
represents major changes.

You are confusing RRV and SemVer. :slight_smile:

Quoth the RubyGems Rational Versioning Policy:
Nevermo^W"A category 3 change (incompatible) will increment the major
build number and reset the minor and build numbers."

It doesn’t say anything about pre-1.0.0 releases. :wink:

Though, RRV works best for existing libraries adopting it, and
SemVer works best for fresh, newborn libraries.

–
Phillip G.

twitter.com/phgaw
phgaw.posterous.com

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

5

I was not aware of this difference between RRV and SemVer before;
Interesting to know! Thanks.

As stated in the README, Alf actually follows SemVer (I must
add that having to increase the major number immediately after
birthday looks very difficult in practice). Now that I know this
subtle distinction, I’ll check if I can follow RRV more strictly in
the future…

Did rubgems itself has followed RRV in the last few months ??

Thanks for reporting this difference, though.

Bernard

On Wed, Jul 13, 2011 at 10:52 PM, Phillip G. <

6

On Wed, Jul 13, 2011 at 11:02 PM, Bernard L. [email protected]
wrote:

As stated in the README, Alf actually follows SemVer (I must
add that having to increase the major number immediately after
birthday looks very difficult in practice).

I’d make it clear in your announcements that you follow SemVer. Makes
it easier for us po’ folk to see what level of changes a given release
brings with it at a glance. :slight_smile:

Further, it all depends on how you define “birthday”. Ideally, the
first public release (the “birthday to the rest of the world”) is
1.0.0, making this whole issue moot.

Otherwise, I’d jsut tag the first public released of an unfinished gem
as 0.1.0, and go from there.

Now that I know this
subtle distinction, I’ll check if I can follow RRV more strictly in
the future…

If you already picked SemVer, stick with it. In the end, RRV and
SemVer are similar enough that your releases follow RRV and SemVer at
once, once you hit the Big One.

Did rubgems itself has followed RRV in the last few months ??

AFAIK, the policy is a result of the recent deprecation hubbub, thus
RubyGems should follow this policy from now on. If it does, well,
we’ll see that when the releases come rolling in. I have to say,
though, that I’m sure Evan P. as release manager will be a
stickler for these rules. :slight_smile:

–
Phillip G.

twitter.com/phgaw
phgaw.posterous.com

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

7

Thanks for the tip.

I’ve already made version policy clearer in README.

From now on, I’ll add a note about SemVer and current status
in annoucements, that a brilliant idea :slight_smile:

B

On Wed, Jul 13, 2011 at 11:14 PM, Phillip G. <

8

Phillip G. wrote in post #1010560:

On Wed, Jul 13, 2011 at 11:02 PM, Bernard L. wrote:

As stated in the README, Alf actually follows SemVer (I must add
that having to increase the major number immediately after
birthday looks very difficult in practice).

Why? What’s the stigma against increasing major version numbers?

For example, I’ve been following RRV in my open-source projects
since I first read the RubyGems user manual back in 2006. Some of
them have very “high” version numbers already, and I do not hesitate
to release major versions right after bug fixes because the changes
contained in a release should dictate the version number:

ruby-vpi 21.1.0
test-loop 12.2.0
erbook 9.2.1
inochi 6.1.0
rumai 4.1.2
gerbil 3.1.0
detest 3.1.3
dfect 2.2.0
test-unit-must 1.0.0
ember 0.3.1
kernel_hash 0.0.0
babelfish 0.0.1

Further, it all depends on how you define “birthday”. Ideally, the
first public release (the “birthday to the rest of the world”) is
1.0.0, making this whole issue moot.

Otherwise, I’d jsut tag the first public released of an unfinished
gem as 0.1.0, and go from there.

What is an “unfinished” gem? What, aside from a 1.0.0 version
number, really makes a gem “finished”?

In the end, RRV and SemVer are similar enough that your releases
follow RRV and SemVer at once, once you hit the Big One.

I don’t understand why a “1.0” (or “Big One” as you say) release is
given such overwhelming importance in open-source software.

If this was commercial software (published in big, singular
releases, optionally followed by “patches” to the company’s
embarrassment) then I would agree that the “1.0” convention makes
sense. But this is open-source software, which continually changes,
improves, and evolves: a “1.0” release is like any other release!

I really hope that we (open-source developers) put aside the need to
productize our open-source software like commercial software is,
overcome the stigma of “high” version numbers, and learn to accept
that change is the life-blood of open-source software: it is never
really “finished”, is it? And without regular maintenance, it will
age, rot, and fall into obscurity. :frowning:

Did rubgems itself has followed RRV in the last few months ??

I’m sure Evan P. as release manager will be a stickler for
these rules. :slight_smile:

He had better! Otherwise it defeats the whole purpose of RRV. :frowning:

9

On Thu, Jul 14, 2011 at 8:27 PM, Suraj K. [email protected]
wrote:

What is an “unfinished” gem? What, aside from a 1.0.0 version
number, really makes a gem “finished”?

Feature-completeness. Whatever I say is finished.

I don’t understand why a “1.0” (or “Big One” as you say) release is
given such overwhelming importance in open-source software.

It usually means that the author considers her work done. It does
everything it is supposed to do, is free from bugs, and doesn’t
require further work. That’s the theory, anyway.

I really hope that we (open-source developers) put aside the need to
productize our open-source software like commercial software is,
overcome the stigma of “high” version numbers, and learn to accept
that change is the life-blood of open-source software: it is never
really “finished”, is it? And without regular maintenance, it will
age, rot, and fall into obscurity. :frowning:

Commercial software and open source are not opposites. See, for
example, RedHat and Novell, or Citrix’ XenServer. Or, in fact, the BSD
license and GPL.

–
Phillip G.

twitter.com/phgaw
phgaw.posterous.com

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

10

On Jul 13, 4:52pm, Phillip G. [email protected]
wrote:

It doesn’t say anything about pre-1.0.0 releases. :wink:

Then it needs to, b/c otherwise RRV is wrong.

When you get to version v11.0 you realize just how wrong :wink:

0.x versions are often undergoing massive changes. It is not rational
to bump the major number every time the “initial development series”
changes. So, for 0.x, minor number is really the major number. I guess
one can think of it as a “semantic shift”.

Personally I have developed a different tact from experience. I use
the minor number for API changes and the major number for overarching
philosophical design changes. (But still 0.x is shifted).

11

On Fri, Jul 15, 2011 at 4:03 AM, Intransition [email protected]
wrote:

Then it needs to, b/c otherwise RRV is wrong.

Or not relevant to your use case. As I’ve also written:

“Though, RRV works best for existing libraries adopting it, and
SemVer works best for fresh, newborn libraries.”

When you get to version v11.0 you realize just how wrong :wink:

Chrome’s at version 12, without any major (much less “philosophical”)
changes between versions.

What it comes down to is that version numbers are just numbers,
without any inherent meaning of their own. Otherwise, where’s all the
versions between Access 2.0 and Access 7.0? What happened to .NET 3.2?

0.x versions are often undergoing massive changes. It is not rational
to bump the major number every time the “initial development series”
changes. So, for 0.x, minor number is really the major number. I guess
one can think of it as a “semantic shift”.

Here’s a thought: don’t bump the version number pre-1.0 if you don’t
have to. Policy, no matter which one, doesn’t replace good sense. Or
adopt SemVer for your new libraries.

–
Phillip G.

twitter.com/phgaw
phgaw.posterous.com

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz