headers
secretary | 1 Sep 2009 09:23

NYC LOCAL: Tuesday 1 September 2009 NYLUG Python Workshop

<blockquote
  what="official NYLUG Python Workshop announcement"
  note="This is a regular event.
        The NYLUG Python Workshop meets every other Tuesday."
  edits="">

 From: NYLUG Announcements <info <at> nylug.org>
 To: NYLUG Announcements <nylug-announce <at> nylug.org>
 Date: Mon, 31 Aug 2009 09:20:01 -0400 (EDT)
 Subject: [nylug-announce] NYLUG Python Workshop, (TOMORROW) September 01 6:00PM-8:00PM

 This is a reminder for the event detailed below.

 PYTHON WORKSHOP
 Date: Tuesday, September 01, 2009
 Time: 6:00pm
 Duration: 2 hours
 Location: NY Public Library Hudson Park Branch, 66 Leroy St., NY NY 10014

 Topics:
   General discussion about Python, and working through example code.
   Bring something to discuss! There's a blackboard, chalk, and Internet
   access.  Notebook computers are helpful but not required.
   All levels of Python experience from totally new to experienced welcome!

 Description:
   We will continue meeting on a bi-weekly basis at the Hudson Library at
   66 Leroy St New York, NY 10014.

   It is helpful, but not necessary to have a notebook computer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
DFS | 1 Sep 2009 15:08

Re: NYC LOCAL: Tuesday 1 September 2009 NYLUG Python Workshop

secretary <at> lxny.org wrote:

> Location: NY Public Library Hudson Park Branch, 66 Leroy St., NY NY 10014
> We meet in the basement.

BWAHA!!!!

Can you cheapass freeloaders be any more stereotypical?

> There's a blackboard, chalk, and Internet access.

http://www.classroomsforkenya.org.uk/photos/11.jpg

> Notebook computers are helpful but not required.

Who needs a computer to discuss and display computer programming languages 
and techniques?
Permalink | Reply | 0 comments |
headers
Bob Fry | 2 Sep 2009 06:09
Favicon

Re: why aren't gnu utils normalized?

>>>>> "B" == Barry Margolin <barmar <at> alum.mit.edu> writes:

Thanks for the followups all.

    B> I think the answer to his general question, then, is that it
    B> would take an enormous amount of work to get all commands to be
    B> consistent this way.

Work, yes, but I don't think enormous. If I weren't an old Fortran
dino I might volunteer, but too many years with that beast gave me
allergies to pointers.

    B> Reconciling all of these, including dealing with some
    B> of the conflicts (especially with traditional single-letter
    B> options) would be a huge undertaking.

Well, I wouldn't touch the traditional single-letter options.
Instead, fix the double-dash options.  Again, I don't think it would
be huge.

    B> Traditionally, the Unix model has been to NOT try to replicate
    B> all these options in every command.  The Unix Way is to have a
    B> toolkit of specialized commands, which can be combined to
    B> produce the results you want.

    B> So if you have two files that are sorted numerically, and want
    B> to join them, you first run them through sort(1) to re-sort
    B> them lexicographically, then run those through join, and
    B> finally sort the result numerically.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Miles Bader | 2 Sep 2009 11:57
Picon
Gravatar

Re: why aren't gnu utils normalized?

Bob Fry <bobfry <at> mailinator.com> writes:
> Well, I wouldn't touch the traditional single-letter options.
> Instead, fix the double-dash options.  Again, I don't think it would
> be huge.

The various programs which compose GNU were written by many different
people, and are often still maintained separately, and the GNU project
doesn't tend to be heavy-handed about imposing structure from above.

They do try and make recommendations and set some standards where it
seems useful, thus the "GNU coding standards".

One part of the GNU coding standards is a list of existing command-line
options; if you write a new program or add a new option, it's a good
idea to try and find an existing option which fits, and use that.

If you have the info manual for the GNU coding standards installed, you
can look at the info node  "(standards) Option Table" to see it.
E.g., in Emacs, do "C-h i g (standards) Option Table RET"]

-Miles

--

-- 
We have met the enemy, and he is us.  -- Pogo
Permalink | Reply | 2 comments |
headers
Bob Fry | 2 Sep 2009 17:03
Favicon

Re: why aren't gnu utils normalized?

>>>>> "MB" == Miles Bader <miles <at> gnu.org> writes:

    MB> One part of the GNU coding standards is a list of existing
    MB> command-line options; if you write a new program or add a new
    MB> option, it's a good idea to try and find an existing option
    MB> which fits, and use that.

Ha!  I never looked at it; but it includes this:

"One of the advantages of long-named options is that they can be
consistent from program to program.  For example, users should be able
to expect the "verbose" option of any GNU program which has one, to be
spelled precisely `--verbose'."

Though the wording and the example don't fully explain things.
"*They* can be consistent..."  What is *they*? Merely the spelling, or
also the functionality?

So *maybe* one of the uses of the long-named options is what I am
proposing...it just hasn't been implemented yet.
--

-- 
If you ever reach total enlightenment while drinking beer, I bet
you could shoot beer out of your nose.
 - Jack Handey
Permalink | Reply | 1 comment |
headers
secretary | 2 Sep 2009 21:28

NYC LOCAL: Wednesday 2 September 2009 NYCBUG: Jeffrey Hsu on How to Get Started with Kernel Programming

<blockquote
  what="official NYC*BUG announcement"
  edits="">

 Date: Wed, 02 Sep 2009 14:43:47 -0400
 To: announce <at> lists.nycbug.org
 From: NYC*BUG Announcements <announce <at> lists.nycbug.org>
 Subject: [announce] NYC*BUG Tonight

 LAST MINUTE NOTE: if anyone has a digital audio recorder, please bring 
 it to the meeting.

 Wednesday, September 02, 2009

 Jeffrey Hsu on How to Get Started with Kernel Programming

 6:45 PM, Suspenders Restaurant
 http://www.suspendersbar.com/location.php

 http://www.suspendersbar.com/location.php

 This talk is intended to introduce kernel programming for the absolute 
 novice. We will cover:
 # basic setup
 # building and booting test kernels
 # how to write your first system call
 # a quick overview of the major subsystems including
 # kernel locking and synchronization primitives
 # device drivers
 # VFS layer
(Continue reading)

Permalink | Reply | 0 comments |
headers
Moshe Goldfarb | 2 Sep 2009 22:12
Picon
Favicon

Re: NYC LOCAL: Wednesday 2 September 2009 NYCBUG: Jeffrey Hsu on How to Get Started with Kernel Programming

On 2 Sep 2009 15:28:39 -0400, secretary <at> lxny.org wrote:

> <blockquote
>   what="official NYC*BUG announcement"
>   edits="">
> 
>  Date: Wed, 02 Sep 2009 14:43:47 -0400
>  To: announce <at> lists.nycbug.org
>  From: NYC*BUG Announcements <announce <at> lists.nycbug.org>
>  Subject: [announce] NYC*BUG Tonight
> 
>  LAST MINUTE NOTE: if anyone has a digital audio recorder, please bring 
>  it to the meeting.

I have an 8-track cartridge tape recorder.
Does that count?

Seems like a perfect match of Linux.
Permalink | Reply | 0 comments |
headers
Barry Margolin | 3 Sep 2009 03:07
Picon
Favicon
Gravatar

Re: why aren't gnu utils normalized?

In article <d469wfrt.fsf <at> mailinator.com>,
 Bob Fry <bobfry <at> mailinator.com> wrote:

> >>>>> "MB" == Miles Bader <miles <at> gnu.org> writes:
> 
>     MB> One part of the GNU coding standards is a list of existing
>     MB> command-line options; if you write a new program or add a new
>     MB> option, it's a good idea to try and find an existing option
>     MB> which fits, and use that.
> 
> Ha!  I never looked at it; but it includes this:
> 
> "One of the advantages of long-named options is that they can be
> consistent from program to program.  For example, users should be able
> to expect the "verbose" option of any GNU program which has one, to be
> spelled precisely `--verbose'."
> 
> Though the wording and the example don't fully explain things.
> "*They* can be consistent..."  What is *they*? Merely the spelling, or
> also the functionality?
> 
> So *maybe* one of the uses of the long-named options is what I am
> proposing...it just hasn't been implemented yet.

The idea is that IF two programs have a similar feature, long option 
names allow them to be invoked with the same option name, since there's 
not likely to be a conflict problem like there is with single-letter 
options.

But this doesn't imply that all programs should have similar features.
(Continue reading)

Permalink | Reply | 0 comments |
headers
parag | 7 Sep 2009 08:34
Picon

Vi is taking a lot of time to exit

What could be the possible problems
I have a lot of space in my quota ( we have restricted usage limits )

Is there any diagnostics that I can run to find out the problem
Permalink | Reply | 1 comment |
headers
secretary | 7 Sep 2009 15:53

NYC LOCAL: Tuesday 8 September 2009 Lisp NYC End of Summer Bash

<blockquote
  what="official Lisp NYC announcement"
  edits="some paragraphs reformatted by Emacs">

 Date: Wed, 02 Sep 2009 12:23:17 -0400
 From: heow <lists <at> alphageeksinc.com>
 To: LISP NYC <lisp <at> lispnyc.org>
 Subject: [Lisp] Lisp Meeting, Sept 8: End of Summer Lisp Bash

 Join us Tuesday, September 8th from 7:00-XYZZY for LispNYC's End
 of Summer Lisp Bash!

 Help put the closing parenthesis in "(summer)" on a scenic
 rooftop patio with an incredible view of the Hudson and the
 George Washington Bridge.  Amenities include BBQ, tables, chairs
 and even a pool (...that fits 2).

  * basic food and beverages will be served
  * BYOB
  * BYOM: bring your own meat if you'd like to grill up anything special, like that emu.

 Directions: 

   304 West 92nd (between West End & Riverside) 
   Take elevator to the 9th floor
   Go upstairs to the roof deck

 Many thanks to Ray de Lacaze for hosting.

 - Heow
(Continue reading)

Permalink | Reply | 0 comments |

Gmane