Re: Perl Tech meeting Tues Oct 14th - Shell-Shocker CGI and Perl DoS bugs
While today is a holiday for some, tomorrow is Boston.PM anyway. (Worse, next month we're on 11/11.) And Boston Perl Monger's 2nd Tuesday comes as late as possible this month, so falls the day before BLU 3rd Wednesday. (I hear some operating system also issues patches that day, doesn't affect me.) TOPIC: Shell-Shocker CGI and Perl DoS bugs DATE: Tuesday, October 14 TIME: 7:00 – 10:00 PM ROOM: E51-376 SPEAKER: Bill Ricker (lead) We will examine the implications for the ShellShock BASH bug for Perl -- it's much wider than just about BASH CGI or even Perl CGI scripts -- and also a recently discovered/fixed but comparably long-lurking Perl DoS bug in a core module (Data::Dumper stack smash CVE-2014-4330) and how is it possibly remotely triggerable. The good news is ShellShocker was slightly over-hyped; unlike Heartbleed, this one does NOT generally affect the Internet of Things, you internet-enabled toaster is likely immune. But Windows and Mac are not entirely immune to this Linux bug. [ Anyone who has examined either bug or its implications is welcome to contribute or co-present - contacting me off-list is recommended, although in our interactive style I'll cheerfully include ambush collaborators. ] Boilerplate details Tech Meetings are held on the 2nd Tuesday of every month at MIT building E51, Sloan School Tang Center [not the other Tang building!] nearer to Kendall Sq than Mass Ave. (directions http://boston-pm.wikispaces.com/MIT+Directions). Talk begins at 7:30. Refreshments in the hallway prior. RSVP for count encouraged but not required, to bill.n1...@gmail.com or Boston-PM list, by 4pm Tuesday. (NOTE: we're staying in the wider room 376 where we were in summer, after being in squarish 372 for winter/spring.) website - boston.pm.org ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On Tue, 2009-07-14 at 15:32 -0400, Joshua Judson Rosen wrote: > > The simplistic self.foo = self.compute_foo() will trigger a call to > > __getattr__, so you can't use that within __getattr__. > > That's not true; it *will*, however, trigger a call to __settattr__, > if it exists; that's what you're thinking of :) > > cf. http://docs.python.org/reference/datamodel.html#object.__setattr__ > > __getattr__, however, is free to just do `self.foo = ...'. Thanks for the correction. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Lloyd Kvam writes: > > On Mon, 2009-07-13 at 22:59 -0400, Paul Lussier wrote: > > Lloyd Kvam writes: > > > > > You've already gotten two useful responses. I'd just like to add that > > > typically, the object attributes are referenced directly: > > > rect.length * rect.width > > > > Lloyd, thanks. But what if the attribute isn't set yet? If I have > > self.foo, and self.foo hasn't yet been set, I want it to go and get set, > > then return the correct value. > > If the initial set value is a simple constant, make it a class attribute > with the default value. The object can override the attribute with a > different value when that value is determined. > > > > I get the impression the __getattr__() method helps here, > > If the value will be computed on demand, __getattr__ is one way to go. > def __getattr__(self, attr): > if attr == 'foo': > return self.compute_foo() > elif > else: > raise AttributeError( attr + ' is invalid name') > > This is the 'traditional' approach. __getattr__ is *only* called when > an attribute is not found. If you wanted to save the computed value, so > that __getattr__ was no longer used: > self.__dict__['foo'] = self.compute_foo() > return self.foo > > The simplistic self.foo = self.compute_foo() will trigger a call to > __getattr__, so you can't use that within __getattr__. That's not true; it *will*, however, trigger a call to __settattr__, if it exists; that's what you're thinking of :) cf. http://docs.python.org/reference/datamodel.html#object.__setattr__ __getattr__, however, is free to just do `self.foo = ...'. -- Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Lloyd Kvam writes: > If the value will be computed on demand, __getattr__ is one way to go. > def __getattr__(self, attr): > if attr == 'foo': > return self.compute_foo() > elif > else: > raise AttributeError( attr + ' is invalid name') > > This is the 'traditional' approach. __getattr__ is *only* called when > an attribute is not found. If you wanted to save the computed value, so > that __getattr__ was no longer used: > self.__dict__['foo'] = self.compute_foo() > return self.foo > > HTH Very much so! -- Thanks, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On Mon, 2009-07-13 at 22:59 -0400, Paul Lussier wrote: > Lloyd Kvam writes: > > > You've already gotten two useful responses. I'd just like to add that > > typically, the object attributes are referenced directly: > > rect.length * rect.width > > Lloyd, thanks. But what if the attribute isn't set yet? If I have > self.foo, and self.foo hasn't yet been set, I want it to go and get set, > then return the correct value. If the initial set value is a simple constant, make it a class attribute with the default value. The object can override the attribute with a different value when that value is determined. > > I get the impression the __getattr__() method helps here, If the value will be computed on demand, __getattr__ is one way to go. def __getattr__(self, attr): if attr == 'foo': return self.compute_foo() elif else: raise AttributeError( attr + ' is invalid name') This is the 'traditional' approach. __getattr__ is *only* called when an attribute is not found. If you wanted to save the computed value, so that __getattr__ was no longer used: self.__dict__['foo'] = self.compute_foo() return self.foo The simplistic self.foo = self.compute_foo() will trigger a call to __getattr__, so you can't use that within __getattr__. The new-style python classes allow for cleaner dispatching of your attribute computations using properties, but for a small number of names, __getattr__ will do just fine. If there is no setter method and foo is always computed, your class could be coded: foo = property( compute_foo) > I just don't > quite get it yet. HTH > > -- > Thanks, > Paul -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Lloyd Kvam writes: > You've already gotten two useful responses. I'd just like to add that > typically, the object attributes are referenced directly: > rect.length * rect.width Lloyd, thanks. But what if the attribute isn't set yet? If I have self.foo, and self.foo hasn't yet been set, I want it to go and get set, then return the correct value. I get the impression the __getattr__() method helps here, I just don't quite get it yet. -- Thanks, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On 07/11/2009 11:44 PM, Paul Lussier wrote: > In perl, I can use the AUTOLOAD feature to dynamically create methods, > something like this: It looks like in perl6 you get this for free. I'm just getting started with it though. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On Sat, 2009-07-11 at 23:44 -0400, Paul Lussier wrote: > How do I create dynamically created methods in python classes? > > For example, if I have a number of member variables which I want to > get > or set, I don't want to have to create getters and setters for each > attribute, since the code would largely be the same, just the variable > I'm dealing with would be different. You've already gotten two useful responses. I'd just like to add that typically, the object attributes are referenced directly: rect.length * rect.width to compute area. Do not use: rect.get_length() * rect.get_width(). getter/setter methods get created when you some code is needed to control access: room.celsius room.fahrenheit computes the proper value from a single stored temperature (in Kelvin?). The code still looks like a direct reference to the attribute. You have a choice of using __getattr__/__getattribute__/__setattr__ or properties as suggested in the other email responses. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/09 23:44, quoth Paul Lussier:
> Hi Folks,
>
> How do I create dynamically created methods in python classes?
>
> For example, if I have a number of member variables which I want to get
> or set, I don't want to have to create getters and setters for each
> attribute, since the code would largely be the same, just the variable
> I'm dealing with would be different.
>
> In perl, I can use the AUTOLOAD feature to dynamically create methods,
> something like this:
>
> sub AUTOLOAD {
> my ($self, @args) = @_;
> my $method = $AUTOLOAD;
> $method =~ s/.*:://;
> if ($method ne 'DESTROY') {
> # Return the structure/value pointed to by $self->{KEY}, or, set it
> # if it's not a ref to something else.
> if (exists $self->{"_$method"} && !ref($self->{"_$method"})) {
> eval("*$AUTOLOAD = "
> . "sub {"
>. " my (\$self, \$value) = assertMinMaxArgs(1, 2, \...@_);"
> . " if (\$value) {"
> . "\$self->{\"_\$method\"} = \$value;"
> . " }"
> . " return \$self->{\"_\$method\"}"
> . "}");
> }
> goto &$AUTOLOAD;
> }
> }
>
> What this AUTOLOAD sub does is this:
>
> - First, it strips everything before the :: leaving just the methodname
>(in perl, method names look like: CLASS::method() )
> - Then, it looks to see if there exists a member variable
>$self->{_}, and that it's not a reference to something
> - Then, it creates an anonymous sub (== a lambda in python I think)
>Each anonymous sub looks like this:
>
> sub {
> my ($self, $value) = assertMinMaxArgs(1, 2, @_);
> if ($value) {
> $self->{_$method} = $value;
> }
> return $self->{_$method}
>
> Essentially, it works like this. If I have a member variable _foo, and
> I want to either set or get _foo, I call a method $self->foo(). If I
> call it as $self->foo(bar), the _foo gets set to bar, otherwise, I get
> back the current value of _foo. So, the anonymous sub above, gets
> re-written as:
>
> sub foo {
> my ($self, $value) = assertMinMaxArgs(1, 2, @_);
> if ($value) {
> $self->{_foo} = $value;
> }
> return $self->{_foo}
>
> I can basically create 1 method which will automagically create for me,
> getter and setter methods for any member variable I create in my class.
> (this is extremely similar, if not identical, to lisp macros!)
>
> For some reason I didn't think python had this capability, but someone
> mentioned to me it did, but I'm not quite sure how I'd write it.
>
> Does anyone have any ideas?
In the Python Coookbook, on (my) page 252 is a section called Section 6.8:
"Avoiding Boilerplate Accessors for Properties".
http://www.ubookcase.com/book/Oreilly/Python.Cookbook.2nd.edition/0596007973/pythoncook2-chp-6-sect-8.html
The code they provide is this:
def xproperty(fget, fset, fdel=None, doc=None):
if isinstance(fget, str):
attr_name = fget
def fget(obj): return getattr(obj, attr_name)
elif isinstance(fset, str):
attr_name = fset
def fset(obj, val): setattr(obj, attr_name, val)
else:
raise TypeError, 'either fget or fset must be a str'
return property(fget, fset, fdel, doc)
but the discussion is important to read and fully understand before you think
you can just plug it in.
- --
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkpaP+kACgkQRIVy4fC+NyRqtQCeLV5oscJqOGQ0zME7KXjvM8n2
HZsAn1OcpB0aif6K1rTbchwdV7GDzn7k
=gJni
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Paul Lussier writes:
>
> Hi Folks,
>
> How do I create dynamically created methods in python classes?
>
> For example, if I have a number of member variables which I want to get
> or set, I don't want to have to create getters and setters for each
> attribute, since the code would largely be the same, just the variable
> I'm dealing with would be different.
Rather than implementing a whole bunch of similar `get_*()' and
`set_*()' methods in Python, you can just define __getattr__() and
__setattr__():
http://docs.python.org/reference/datamodel.html#object.__getattr__
How's that? Perfect fit? :)
Alternately (e.g.: something other than `getters and setters'): can't
you just create a single method that takes an `extra' parameter?
Even if you really do really want to `lots of methods' interface, I'd
still start with unified dispatcher-method--then the other methods
would just be simple wrappers, e.g.:
class C:
def do_stuff(self, key, *args):
print 'doing %s stuff...' % key
do_x = lambda self, *args: self.do_stuff('x', *args)
do_y = lambda self, *args: self.do_stuff('y', *args)
do_z = lambda self, *args: self.do_stuff('z', *args)
You could even set all of those `C.do_*' attributes (which become
methods) automatically, e.g.:
for key in ('xray', 'yankee', 'zulu'):
def do_predispatched_stuff_stuff(self, *args):
return self.do_stuff(key, *rags)
setattr(C, key, do_predispatched_stuff)
--
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
On 9/13/07, Paul Lussier <[EMAIL PROTECTED]> wrote:
> For all those just tuning in, Ben and I are in violent and vocal
> agreement with each other, and at this point are merely quibbling over
> semantics :)
Hey, now, I came here for an argument, and I demand to get one! And
it better be more than just simple contradiction, too. I expect a
connected series of statements intended to establish a proposition!
;-)
(And they say Perl and Python have nothing in common. ;-) )
> To avoid LTS and backslashitis in a regexp, I tend to do something like:
>m|/foo/bar|/bar/baz|g;
The pipe (|) is another often-used regexp syntax character, though.
If I was going to use a single alternate character for m//, I'd prolly
use a bang (!). But I like balanced pairs -- {} or or [] or <> or ()
-- because they nicely identify the start and end of the thing, rather
than simply delimiting it. And if it's a substitution, they let you
separate the pattern from the replacement with whitespace. I
frequently use that to line things up for visual structure (e.g., that
condense_type() function I posted).
> Agreed, though, we ... do things like this slightly differently,
> completely avoiding the $_ dilemma:
That actually wouldn't work for the code I posted, which is
performing multiple transformations on the same string repeatedly.
The fact that you missed that concerns me. *That's* a sign of
inadequate clarity. Looking at the code, I don't see a way to make
that clearer in the code itself, so I guess it needs a comment to that
effect. Phooey. (In my thinking, ideal code needs *no* comments,
because it's so obvious what's going on. Obviously, that's a
theoretical ideal, and not something that happens in practice, but I
think it makes a good goal.)
Unrelated to the above, I think there is an observation to be made
here about "sophisticated" solutions also adding complexity. KISS, as
the saying goes. By introducing variables and loops and control
structures, you're making things more complex, to no gain that I can
see. A simple list of s/// operations does the same thing, and does
not require any additional cognition on the part of the reader. (It
might even be more efficient at runtime, although that would depend on
how smart Perl's optimizer is.)
> ... by we, I mean the company which currently puts food on my table ...
I didn't know Stop and Shop used Perl... ;-)
> Once readability has been achieved, the next
> priority ought to be future maintenance and extensibility, IMO.
Yup.
> Alas, assertNumArgs() is a part of a huge
> home-grown library of routines we have.
Everybody has these. They're extremely useful.
>>> The compelling argument is this: It should be blatantly obvious to
>>> whomever is going to be maintaining your code in 6 months what you
>>> were thinking
>>
>> I do not think I could agree with you more here. The thing you seem
>> to be ignoring in my argument is that "clarity" is subjective and
>> often depends on context. :)
>
> I'm not ignoring it. I'm saying that where you have stopped because
> you think it is sufficiently clear can in fact be made cleaner and
> clearer for the sakes of both clarity and future maintenance.
No, I'm saying that clarity is subjective and depends on context,
and what you deem "clearer" I deem "less clear".
> There are only a finite number of options for any given command [such as
> tar]. The
> same is not true for writing perl code.
True, but I think my point still stands. Verbosity does not equal
clarity, and indeed, verbosity sometimes interferes with readability.
(My choice of tar was, perhaps, a bad example, because I do agree
with your argument WRT to your AMANDA example.)
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
Lloyd Kvam <[EMAIL PROTECTED]> writes: > On Thu, 2007-09-13 at 23:58 -0400, Paul Lussier wrote: >> For all those just tuning in, Ben and I are in violent and vocal >> agreement with each other, and at this point are merely quibbling over >> semantics :) > > As an old Python guy who knows just enough Perl to get it wrong, this > has been educational (and even fun). I'm glad you enjoyed it! That's why I wrote it. I feel that perl has a bad reputation for being "ugly". I believe it's a myth. One can write ugly code in any language. Python went so far as to put white space restrictions place to "enforce" clean code. While that may work to some extent, I've seen ugly python code. I, by no means, claim my way is the best or only way. I don't even claim what I posted will work completely correctly. I was merely trying to demonstrate that there are better ways to write any code such that it is both elegant and pleasing to look at as well as maintain and extend. I would love to see other's interpretations of Ben's code, in any language. How would you accomplish the same in awk, python, ruby, java, C, etc.? -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
[EMAIL PROTECTED] (Kevin D. Clark) writes: > Bill Ricker writes: > >> I highly recommend Damian Conway's book of same title, "Perl Best >> Practices", which recommends a much tamer, consistent readable style >> within a workgroup than he uses in his own code (depending on context) >> -- he suggests one style but encourages each group to decide for >> themselves and take his list of 255 practices as a template for their >> own local standard. > > I will second this. Great book by a great author. Ahm, fellas, we've got a fence-post error here :) This response to Ben is what started all it all: Paul Lussier <[EMAIL PROTECTED]> writes: > "Ben Scott" <[EMAIL PROTECTED]> writes: > >> You don't need to put parenthesis around arguments to split, and you >> don't need to explicitly specify the default pattern match target >> ($_). > > Unfortunately, you both "don't *need* to" and "*can* do" anything in > perl. Often at the same time! This is what leads to very difficult > to read, and more difficult to maintain perl code. [...] > I highly recommend Damian Conway's book "Perl Best Practices", which > outlines these and many other useful pieces of advice. So, Kevin is really thirding ;) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
Bill Ricker writes: > I highly recommend Damian Conway's book of same title, "Perl Best > Practices", which recommends a much tamer, consistent readable style > within a workgroup than he uses in his own code (depending on context) > -- he suggests one style but encourages each group to decide for > themselves and take his list of 255 practices as a template for their > own local standard. I will second this. Great book by a great author. Regards, --kevin -- GnuPG ID: B280F24E Error messages alumni.unh.edu!kdc strewn across my terminal. A vein starts to throb. -- Coy.pm ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
I highly recommend Damian Conway's book of same title, "Perl Best Practices", which recommends a much tamer, consistent readable style within a workgroup than he uses in his own code (depending on context) -- he suggests one style but encourages each group to decide for themselves and take his list of 255 practices as a template for their own local standard. http://www.oreilly.com/catalog/perlbp/ -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
On Thu, 2007-09-13 at 23:58 -0400, Paul Lussier wrote: > For all those just tuning in, Ben and I are in violent and vocal > agreement with each other, and at this point are merely quibbling over > semantics :) As an old Python guy who knows just enough Perl to get it wrong, this has been educational (and even fun). Thanks. -- Lloyd Kvam Venix Corp ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
For all those just tuning in, Ben and I are in violent and vocal
agreement with each other, and at this point are merely quibbling over
semantics :)
"Ben Scott" <[EMAIL PROTECTED]> writes:
> Er, yes. "blah" in this case was meta-syntactic, and I was still
> thinking of the first example in this discussion, which had LTS
> (Leaning Toothpick Syndrome). I will use // if the regexp doesn't
> suffer from LTS. I use m{} or s{}{} when the regexp otherwise
> contains slashes.
Something about the use {} and () in regexps really bothers me. I
think it's because in general, perl overloads too many things to begin
with. To use {} for regexp delimiting is confusing and completely
non-intuitive to me. They are meant to denote either a hash element or
a code block. Trying to make my mind use them for regexps hurts :)
To avoid LTS and backslashitis in a regexp, I tend to do something like:
m|/foo/bar|/bar/baz|g;
The | is close enough to / that it's instantly clear to me.
> "A foolish consistency is the hobgoblin of little minds." -- Ralph
> Waldo Emerson
Yeah, what the old, dead guy said :)
> As a completely non-contrived example, here is an illustration of
> when I think implicit use of $_ is very appropriate.
[...]
> sub condense_type($) {
> # condense a MIME content type to something shorter, for people
> $_ = $_[0];
> s{^text/plain$} {text};
> s{^text/html$} {html};
> s{^text/css$} {css};
> s{^text/javascript$}{jscript};
> s{^text/xml$} {xml};
> s{^text/} {};
> s{^image/.*}{image};
> s{^video/.*}{video};
> s{^audio/.*}{audio};
> s{^multipart/byteranges}{bytes};
> s{^application/}{};
> s{^octet-stream$} {binary};
> s{^x-javascript$} {jscript};
> s{^x-shockwave-flash$} {flash};
> s{\*/\*}{stars};# some content gets marked */*
> return $_;
> }
>
> I could have used a regular named variable (say, $type) and
> repeated "$type =~" over and over again for 14 lines. I believe
> that would actually harm the readability of the code.
Agreed, though, we (by we, I mean the company which currently puts
food on my table :) do things like this slightly differently,
completely avoiding the $_ dilemma:
$match = shift;
%mimeTypes =
('^text/plain$' => "text" ,
'^text/html$' => "html" ,
'^text/css$'=> "css" ,
'^text/javascript$' => "jscript",
'^text/xml$'=> "xml" ,
'^text/'=> "" ,
'^image/.*' => "image" ,
'^video/.*' => "video" ,
'^audio/.*' => "audio" ,
'^multipart/byteranges' => "bytes" ,
'^application/' => "" ,
'^octet-stream$'=> "binary" ,
'^x-javascript$'=> "jscript",
'^x-shockwave-flash$' => "flash" ,
'*/*' => "stars" ,# some content gets marked */*
);
foreach my $mtype (keys %mimeTypes) {
if ($mtype =~ /$match/)
return $mimeType{$mtype};
}
}
Also, the foreach could be written as:
map { ( $match =~ /$_/) && return $mimeTypes{$_}} keys %mimeTypes
Though I find this completely readable, it suffers from the problem
that it's not easily extensible. If you decide you need to do more
processing within the loop, the foreach is much easier to extend. You
just plonk another line in there and operate on the already existing
variables. With the map() style loop, this becomes more difficult.
So, though I love map(), I would have to argue this is not the best
place to use it. Once readability has been achieved, the next
priority ought to be future maintenance and extensibility, IMO.
> As a counter-example from the same script, here's something using
> explicit names and grouping which isn't strictly needed, because I
> find it clearer:
>
> sub condense_size($) {
> # consense a byte-count into K/M/G
> my $size = $_[0];
> if($size > $gigabyte) { $size = ($size / $gigabyte) . "G"; }
> elsif ($size > $megabyte) { $size = ($size / $megabyte) . "M"; }
> elsif ($size > $kilobyte) { $size = ($size / $kilobyte) . "K"; }
> return $size;
> }
I tend to like this style too, though I'd use a slightly different
syntax. It's otherwise exactly the same.
my $size = shift;
($size > $gigabyte) && { return (($size/$gigabyte) . "G")};
($size > $megabyte) && { return (($size/$megabyte) . "M")};
($size > $kilobyte) && { return (($size/$kilobyte) . "K")};
Or, perhaps, if you wanted to be a little more cleverer:
my %units = ($gigabyte => sub { int($_[0]/$gigabyte) . 'G'},
$megabyte => sub { int($_[0]/$megabyte) . 'M'},
$kilobyte => sub { int($_[0]/$kilobyte) . 'K'},
);
foreach my $base (sort {$b <=> $a } keys %units) {
if ($size > $base) {
print ($units{$base}->($size),"\n");
last;
}
}
This last approach is both too clever by 1, but also, slightl
Re: Perl best practices
On 13 Sep 2007 12:10:58 -0400, Kevin D. Clark <[EMAIL PROTECTED]> wrote: > If I write anything else, it would just be a combination of me > nit-picking for no purpose and hot air. Welcome to the Internet! ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
On 9/13/07, Paul Lussier <[EMAIL PROTECTED]> wrote:
> When writing code which will be used, looked at, modified, and
> maintained by a group of people, it is best to agree upon and strictly
> adhere to a common set of coding standards.
Yes. But when the designated group of people is "all of humanity",
the problem of agreeing on said standards becomes difficult. :)
> I find both of these bothersome :) *I* prefer:
>
> @foo = split (/blah/);
Er, yes. "blah" in this case was meta-syntactic, and I was still
thinking of the first example in this discussion, which had LTS
(Leaning Toothpick Syndrome). I will use // if the regexp doesn't
suffer from LTS. I use m{} or s{}{} when the regexp otherwise
contains slashes.
> @foo = split (/blah/);
> @foo = split (/blah/, $actualVariableName);
> The former implies $_, which need not be explicitly stated in this case.
Right. That's exactly what I was saying. ;-)
> map { grep { ... $_ } $_ } @foo;
>
> Which $_ is which, and where is each getting it's data from?
Like I said, I use things like parenthesis, braces, named variables,
etc., liberally when I find the meaning/intent is not obvious in
context. But it's a case-by-case call, not an absolute, inviolable
rule.
"A foolish consistency is the hobgoblin of little minds." -- Ralph
Waldo Emerson
As a completely non-contrived example, here is an illustration of
when I think implicit use of $_ is very appropriate. It's from a
Squid log analysis tool I wrote, where I wanted to condense the MIME
content type into something smaller and more appropriate for a log
report. Here's the code (as usual, view in a monospace font to get
this to line up properly):
sub condense_type($) {
# condense a MIME content type to something shorter, for people
$_ = $_[0];
s{^text/plain$} {text};
s{^text/html$} {html};
s{^text/css$} {css};
s{^text/javascript$}{jscript};
s{^text/xml$} {xml};
s{^text/} {};
s{^image/.*}{image};
s{^video/.*}{video};
s{^audio/.*}{audio};
s{^multipart/byteranges}{bytes};
s{^application/}{};
s{^octet-stream$} {binary};
s{^x-javascript$} {jscript};
s{^x-shockwave-flash$} {flash};
s{\*/\*}{stars};# some content gets marked */*
return $_;
}
I could have used a regular named variable (say, $type) and repeated
"$type =~" over and over again for 14 lines. I believe that would
actually harm the readability of the code. I find it clearer with use
of implicit $_, because it puts the focus on the fact that I'm doing a
bunch of transformations on the same thing, over and over again.
As a counter-example from the same script, here's something using
explicit names and grouping which isn't strictly needed, because I
find it clearer:
sub condense_size($) {
# consense a byte-count into K/M/G
my $size = $_[0];
if($size > $gigabyte) { $size = ($size / $gigabyte) . "G"; }
elsif ($size > $megabyte) { $size = ($size / $megabyte) . "M"; }
elsif ($size > $kilobyte) { $size = ($size / $kilobyte) . "K"; }
return $size;
}
>> Explicitly specifying $_ over and over again just clutters up the
>> code with pointless syntax. It's one more thing my brain has to
>> recognize and process.
>
> Right, which is why you shouldn't depend upon $_ in these contexts and
> explicitly state a variable name ...
A named variable would be *two* more things. ;-)
> s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
Er, yah, that would be even better. Not sure why I didn't just use
s/// with /g when I wrote that the first time around.
(The actual script in my ~/bin/ has several lines of comments
explaining certain design decisions, but that's one one of them.)
> my $file = shift;
You're using an implicit argument to shift there. ;-)
> The compelling argument is this: It should be blatantly obvious to
> whomever is going to be maintaining your code in 6 months what you
> were thinking
I do not think I could agree with you more here. The thing you seem
to be ignoring in my argument is that "clarity" is subjective and
often depends on context. :)
>> I write Perl programs with the assumption that the reader
understands Perl ...
>
> ... even those who *claim* to know the language, often times are
> just fooling themselves.
I'm not going to penalize the competent because there are others who
are incompetent.
>> Many say similar things about Unix. Or Emacs. :-) I'm don't argue
>> that one approach is right and the other wrong, but I do think that
>> both approaches have their merits.
>
> Which approaches are you talking about? Approaches to learning, or to
> writing?
Yes. :)
Let me restate: A pattern which is powerful and easy-to-use is
sometimes unavoidably non-obvious.
Or perhaps an example of a similar principle in a different context:
When invoking tar from a shell script, which of the following do you
prefer?
tar --create --gzip --verbose -
Re: Perl best practices
Paul Lussier writes: > (/me waiting for Kevin to pipe in here in 4...3...2...1... ;) Ben and Paul are competent Perl programmers. They write good code. Code should be written to be clear. While it is nice if code written in a given language is understandable by people who don't know the language, this property isn't guaranteed. Cryptic one-liners can be hard to follow, but they can also be beautiful and useful. If I write anything else, it would just be a combination of me nit-picking for no purpose and hot air. Kind regards, --kevin -- GnuPG ID: B280F24E It is best to forget the great sky alumni.unh.edu!kdc And to retire from every wind -- Mumon ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
"Ben Scott" <[EMAIL PROTECTED]> writes:
> Personally, in the proper context, I find this:
When writing code which will be used, looked at, modified, and
maintained by no one else, doing whatever makes you happy and more
efficient makes sense, and is more efficient and expedient.
When writing code which will be used, looked at, modified, and
maintained by a group of people, it is best to agree upon and strictly
adhere to a common set of coding standards. This makes the entire
group more eficient. The personal likes and/or dislikes of anyone
person may or may not bother anyone else in the group.
> @foo = split m{blah};
>
> to be easier to read and comprehend at a glance than this:
>
> @foo = split (m{blah}, $_);
I find both of these bothersome :) *I* prefer:
@foo = split (/blah/);
or: @foo = split (/blah/, $actualVariableName);
The former implies $_, which need not be explicitly stated in this case.
The latter clearly denotes where you're getting your data from.
$_ has a *lot* of magical properties which can really screw things up,
especially in cases like:
map { grep { ... $_ } $_ } @foo;
Which $_ is which, and where is each getting it's data from? This is
where the use of named variables I find to be better than just
depending upon built-ins like $_.
> Explicitly specifying $_ over and over again just clutters up the
> code with pointless syntax. It's one more thing my brain has to
> recognize and process.
Right, which is why you shouldn't depend upon $_ in these contexts and
explicitly state a variable name (which should also be my'ed into the
proper scope :)
> I don't arbitrarily assign to $_ and use it at random, the way some
> people do. And I do make use of parenthesis, braces, and such, even
> when they are not needed, when I find it makes the code clearer. But
> I also leave them out when I find it makes the code clearer.
No arguments with that. In general, IMO, clarity is of the utmost
importance. There are many "best practices" which can help aid
clarity though. I find one such practice is to always use func(args)
because it makes it blatantly obvious you're calling a function.
(perhaps the one exception is with print, but even then, I find myself
very often using it there too. To me:
print (join("\s", "Some text", func(args), "more text",),
"\n"
);
is far more readable than
print join " ", "Some text", func(args), "more text", "\n";
In the former, if I need to add "stuff" to the join, it's blatantly
obvious where it goes. In the latter, it is not.
> For a slightly less contrived example, take a script which trims
> leading and trailing whitespace from each line in an input file. I
> already have one implementation, and I just wrote up another one.
[...]
> Assuming the reader is familiar with the language, which do you
> think will be easier/quicker to comprehend?
Both of these hurt my eyes! :)
This one is short and sweet:
> #!/usr/bin/perl -wp
> s/^[\x20\t]*//; # trim leading space
> s/[\x20\t]*$//; # trim trailing space
but I'd rewrite it as:
#!/usr/bin/perl -p
s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
For a script which optionally took stdin, I'd write it as:
#!/usr/bin/perl -w
use English;
my $file = shift;
my $FH;
if (!$file) {
*FH = *STDIN;
} else {
open(FH, "$file") || die("Could not open $file: $ERRNO\n";
}
while (my $line = ) {
$line =~ s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
print("$line\n");
}
close(FH);
> It may be true that someone who *isn't* familiar with Perl would
> find it easier to puzzle out the meaning of the longer version.
I'm fairly comfortable with perl. I could puzzle out the meaning
fairly easily. And I'll even concede that as far as most perl, it's
pretty good. But, as is true I'm sure even with my own code, there's
always room for improvement :)
(/me waiting for Kevin to pipe in here in 4...3...2...1... ;)
> But I don't find that a particularly compelling argument.
The compelling argument is this: It should be blatantly obvious to
whomever is going to be maintaining your code in 6 months what you
were thinking :) The easier you make it up front to read your code and
discern your mindset, the less time it take the maintainer in 6
months. Many times, that future maintainer is *you* :)
> I write Perl programs with the assumption that the reader
> understands Perl, the same way I am assuming readers of this message
> understand English. :)
Ahh, yes. But as the superintendent of the Lawrence, MA, School
system has recently shown, even those who *claim* to know the
language, often times are just fooling themselves. Just "axe" him :)
> This may mean Perl, as practiced, is harder to learn than a language
> which is more rigid and always verbose.
I think perl is incredibly easy to learn if you learn from a good
source. The documentation is one such source. Other people's code is
mo
Re: Perl best practices (was: question ... Split operator in Perl)
On 9/13/07, John Abreau <[EMAIL PROTECTED]> wrote: >> s/^[\x20\t]*//; # trim leading space >> s/[\x20\t]*$//; # trim trailing space > > Any particular reason to use [\x20\t] instead of \s ? \s would also eat newlines and similar. At a minimum, it would have to explicitly print with "\n" and use the -n switch instead of the -p switch. Which would be fine. But if the file contains non-native line endings, it can result in those getting mangled, or so I've found. I've got a lot of such files hanging around on my system. Just eating space and tab worked better for me. OTOH, \s should eat other kinds of in-line whitespace that might be encountered, including anything Unicode dishes up. So that might be better for some situations. YMMV. Or, since this is Perl we're talking about: TIMTOWTDI. ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
On Wed, September 12, 2007 9:37 pm, Ben Scott said: > s/^[\x20\t]*//; # trim leading space > s/[\x20\t]*$//; # trim trailing space > Any particular reason to use [\x20\t] instead of \s ? -- John Abreau / Executive Director, Boston Linux & Unix IM: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl CGI charset magic thingy (was: How to be an expert)
On Tue, Jun 13, 2006 at 09:31:14AM -0400, Ben Scott wrote (and I
changed):
> >... but, if so, then I don't understand why. Anyone care to give
> >me their interpretation? [From /usr/share/perl5/Bugzilla/CGI.pm]
> >
> >$self->charset(Param('utf8') ? 'UTF-8' : '');
>
> Well, that looks like the ternary operator (conditional expression).
> To break it out:
>
> if (Param('utf8')) {
> $self->charset("UTF-8");
> }
> else {
> $self->charset(""); # empty string
> }
>
Fixed it for you. I think.
-Mark
signature.asc
Description: Digital signature
Re: perl - sometimes it *does* resemble line noise... (long)
[EMAIL PROTECTED] (Kevin D. Clark) writes:
> Paul Lussier writes:
>
>> And there you have it. 'return map {...} map {...} grep {...}
>> split(...);' Short, concise, no need for a bunch of temp variables
>> that only get used once and thrown away. I like it. Others, well,
>> not so much :)
>
> If this is production code (not "write-once" code) in my opinion the
> original version of the code that you presented is preferable.
As I stated earlier on in the post, what I started with and ended up
with was largely the same. The multi-map/grep/split thing was the
result of a couple refactorings before I came to the same conclusion
:)
> I say this, of course, as somebody who is an enthusiastic Perl
> programmer. Code that is hard to understand and maintain will
> eventually either get rewritten or junked.
Yep, that's why I ended up using a bunch of temp. variables in the
end. Readability/maintainability was enhanced greatly at little/no
cost.
--
Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl - sometimes it *does* resemble line noise... (long)
Paul Lussier writes:
> And there you have it. 'return map {...} map {...} grep {...}
> split(...);' Short, concise, no need for a bunch of temp variables
> that only get used once and thrown away. I like it. Others, well,
> not so much :)
If this is production code (not "write-once" code) in my opinion the
original version of the code that you presented is preferable.
I say this, of course, as somebody who is an enthusiastic Perl
programmer. Code that is hard to understand and maintain will
eventually either get rewritten or junked.
Just another Perl hacker,
--kevin
--
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
-- Tom Waits
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Kevin D. Clark wrote: Another thing to be aware of (but which hasn't come up...yet...in this thread) is that all of the test code that I see here uses signed integers for the bit operations (~ << etc.). The C spec. specifically states that the results of such expressions is system dependent (and hence unportable). FWIW, I also changed my test program to use unsigned integers, and got the same results.--The sall instruction is working as advertised on my Pentium III. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Stephen Ryan writes: > Ooh, here's something interesting. I first tried a test with constants, > and got the warning: left shift count >= width of type" out of gcc. > Then I rewrote the thing to use a loop, and I got correct results out of > it. (This is all on an Athlon64X2.) > > When you described getting the same results for 0 and 32, I tried it > again on my wife's laptop, a Celeron M, and got the same results you > did; just out of curiosity, I looked it up, and gcc generates a 'sall' > instruction to do the actual bit-shift, which on the 80386, PIII and > Celeron M (according to Intel's documentation, your test, and my test, > respectively) all ignore everything but the low 5 bits on the shift > count. The 64-bit Athlon64 apparently doesn't, though, even though I'm > supposedly running in 32-bit compatibility mode. Huh. > > Yet another demonstration of the dangers of of assuming specific > bit-sizes for int, I suppose. Another thing to be aware of (but which hasn't come up...yet...in this thread) is that all of the test code that I see here uses signed integers for the bit operations (~ << etc.). The C spec. specifically states that the results of such expressions is system dependent (and hence unportable). That warning message you saw was gcc doing an OK job warning you of a possible problem. When you added the loop you bamboozled the compiler, but the underlying issue (however small) still remained. Just another compiler guy... --kevin -- GnuPG ID: B280F24E And the madness of the crowd alumni.unh.edu!kdc Is an epileptic fit -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Fri, 2006-03-31 at 21:00 -0500, Jason Stephenson wrote: > Stephen Ryan wrote: > > hostmask = (1 << (32 - n)) - 1 > > netmask = ~ hostmask > > Doh! That's so obvious, so obviously, I overlooked it. ;) Well, yes, of course :-) > > > > 1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' > > bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' > > bits. The 'not' operator flips all the bits for the netmask. > > > > This works for /1 through /32 networks, even though some of those are > > nonsensical. A /0 might break this because of overflow (1 << (32 -n) > > overflows a 32-bit integer); theoretically, it should work even for /0 > > so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop > > computes this correctly, but complains 'warning: left shift count >= > > width of type' while compiling. Anyway, if you're running a /0, you've > > got other, bigger problems. > > Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when > compiling your test program, even with -Wall. When it runs, 0 gives the > same result as 32, so it overflows (silently) on my machine. Ooh, here's something interesting. I first tried a test with constants, and got the warning: left shift count >= width of type" out of gcc. Then I rewrote the thing to use a loop, and I got correct results out of it. (This is all on an Athlon64X2.) When you described getting the same results for 0 and 32, I tried it again on my wife's laptop, a Celeron M, and got the same results you did; just out of curiosity, I looked it up, and gcc generates a 'sall' instruction to do the actual bit-shift, which on the 80386, PIII and Celeron M (according to Intel's documentation, your test, and my test, respectively) all ignore everything but the low 5 bits on the shift count. The 64-bit Athlon64 apparently doesn't, though, even though I'm supposedly running in 32-bit compatibility mode. Huh. Yet another demonstration of the dangers of of assuming specific bit-sizes for int, I suppose. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Stephen Ryan wrote: Can anyone think of a better way to blit an arbitrary number of bits from 0 to 1? Well, let's see Taking advantage of the fact that all of the '1' bits are at the end of the hostmask, you've actually almost gotten it already. hostmask = (1 << (32 - n)) - 1 netmask = ~ hostmask Doh! That's so obvious, so obviously, I overlooked it. ;) 1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' bits. The 'not' operator flips all the bits for the netmask. This works for /1 through /32 networks, even though some of those are nonsensical. A /0 might break this because of overflow (1 << (32 -n) overflows a 32-bit integer); theoretically, it should work even for /0 so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop computes this correctly, but complains 'warning: left shift count >= width of type' while compiling. Anyway, if you're running a /0, you've got other, bigger problems. Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when compiling your test program, even with -Wall. When it runs, 0 gives the same result as 32, so it overflows (silently) on my machine. If you're running a /0, you really must be Root. ;) I'm going to limit the input on my network calculator and throw an error on IPv4 net masks that are not between /8 and /30 inclusive. The reason being that < /8 and > /30 don't really give valid IPv4 networks. Cheers and thanks, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Thu, 2006-03-30 at 20:35 -0500, Jason Stephenson wrote:
> Paul Lussier wrote:
>
> > Yes, more or less. Between you and Jason I've been able to come up
> > with exactly what I need. Thanks a lot for all your help. Why I
> > couldn't see this for myself is beyond me. Of course, this week has
> > been full of me "missing the details" to the point where I somehow
> > managed to mail my taxes to myself from work the other day rather than
> > to my accountant :) So, just in case you wondered, the USPS system is
> > working at peak efficiency !
>
> You're very welcome to the help, and we all have those weeks. It took me
> a while to realize what your real question was.
>
> Once I figured out your question, it was actually rather interesting:
> adding network addresses to interpolate between different networks.
> Trying to answer it allowed me to discover some facts about IPv4
> addresses and masks, so I got to learn something, too.
>
> The thing that I found most interesting is if you use the one or two
> digit kind of "mask," i.e. /19, you can determine how many addresses are
> on the network via the following C code: addresses = 1 << (32 - n).
> Where n is the part of the mask after the /.
>
> I wish I could find a faster way to blit the bits to make the "real"
> mask from the /N style than using a for loop. Only alternative I can
> think of is to use a switch on the 33 possibilities (0-32).--Of course,
> anything < /8 and > /30 doesn't make a "real" network.
>
> Can anyone think of a better way to blit an arbitrary number of bits
> from 0 to 1?
Well, let's see
Taking advantage of the fact that all of the '1' bits are at the end of
the hostmask, you've actually almost gotten it already.
hostmask = (1 << (32 - n)) - 1
netmask = ~ hostmask
1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0'
bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1'
bits. The 'not' operator flips all the bits for the netmask.
This works for /1 through /32 networks, even though some of those are
nonsensical. A /0 might break this because of overflow (1 << (32 -n)
overflows a 32-bit integer); theoretically, it should work even for /0
so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop
computes this correctly, but complains 'warning: left shift count >=
width of type' while compiling. Anyway, if you're running a /0, you've
got other, bigger problems.
> Now, I'm working on a network calculator application that will support
> IPv6 as well. I should probably do it in JavaScript, uh, sorry, AJAX, so
> that the "Web 2.0" people will notice. ;)
>
> Cheers,
> Jason
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
#include
int main()
{
int n;
int netmask,hostmask;
for (n=0;n<=32;n++)
{
hostmask = (1 << (32 -n)) - 1;
netmask = ~hostmask;
printf("n: %d netmask: 0x%08x hostmask: 0x%08x\n",n,netmask,hostmask);
}
return 0;
}
Re: perl and network addresses
Paul Lussier wrote: Yes, more or less. Between you and Jason I've been able to come up with exactly what I need. Thanks a lot for all your help. Why I couldn't see this for myself is beyond me. Of course, this week has been full of me "missing the details" to the point where I somehow managed to mail my taxes to myself from work the other day rather than to my accountant :) So, just in case you wondered, the USPS system is working at peak efficiency ! You're very welcome to the help, and we all have those weeks. It took me a while to realize what your real question was. Once I figured out your question, it was actually rather interesting: adding network addresses to interpolate between different networks. Trying to answer it allowed me to discover some facts about IPv4 addresses and masks, so I got to learn something, too. The thing that I found most interesting is if you use the one or two digit kind of "mask," i.e. /19, you can determine how many addresses are on the network via the following C code: addresses = 1 << (32 - n). Where n is the part of the mask after the /. I wish I could find a faster way to blit the bits to make the "real" mask from the /N style than using a for loop. Only alternative I can think of is to use a switch on the 33 possibilities (0-32).--Of course, anything < /8 and > /30 doesn't make a "real" network. Can anyone think of a better way to blit an arbitrary number of bits from 0 to 1? Now, I'm working on a network calculator application that will support IPv6 as well. I should probably do it in JavaScript, uh, sorry, AJAX, so that the "Web 2.0" people will notice. ;) Cheers, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: >> The 10.0.32/19 is an interesting beast. The systems which live on it >> have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 >> based address (currently restricted to 10.0.33/24 for some reason?!), > > > As far as that restriction goes, I've read of crufty old code which > assume everything follows the old classful model, with strict > boundaries even for subnets. It might be that. To be honest, I think it's more that we just don't have more 255 hosts on that network... yet. We're about to get 50 more systems in which will bring us up to 251. After that, things may well get interesting :) > As for the rest... wow... funky. I do hope all that multi-homing to > the same network is for test/simulation procedures. :) Pretty much. It's to simulate how our product actually works. Though, our product uses this type of setup in a very restricted and controlled manner on a "backend", completely separate and private network. In theory, one installation of our product could approach 255+ hosts in a single installation, in practice, the number of hosts in a single install is rarely more than 10. > Okay, in return for taking the time and effort to explain all that, > I took the time to figure out how to get Perl to convert IP addresses. > Hopefully the following sample code will help you out: [ code elided ] > Is that even close to what you were thinking of? Yes, more or less. Between you and Jason I've been able to come up with exactly what I need. Thanks a lot for all your help. Why I couldn't see this for myself is beyond me. Of course, this week has been full of me "missing the details" to the point where I somehow managed to mail my taxes to myself from work the other day rather than to my accountant :) So, just in case you wondered, the USPS system is working at peak efficiency ! -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Paul Lussier <[EMAIL PROTECTED]> wrote:
> It's confusing.
Sure is! Wow, that's one wacky setup. :)
> The 10.0.32/19 is an interesting beast. The systems which live on it
> have 2 NICs, the primary eth0, which *always* have a 10.0.32/19
> based address (currently restricted to 10.0.33/24 for some reason?!),
As far as that restriction goes, I've read of crufty old code which
assume everything follows the old classful model, with strict
boundaries even for subnets. It might be that.
As for the rest... wow... funky. I do hope all that multi-homing to
the same network is for test/simulation procedures. :)
Okay, in return for taking the time and effort to explain all that,
I took the time to figure out how to get Perl to convert IP addresses.
Hopefully the following sample code will help you out:
!/usr/bin/perl -w
use Socket qw(inet_aton inet_ntoa);
# address and mask in ASCII decimal dotted-quad notation
$addr = '10.0.32.42';
$mask = '255.255.224.0'; # 19
print ("addr: $addr/$mask\n");
# convert to "string" (which is really the four bytes of a 32-bit int)
$addr = inet_aton($addr);
$mask = inet_aton($mask);
# convert to native integers
# the 'N' tells unpack the string is 32-bit int, network order)
$addr = unpack('N', $addr);
$mask = unpack('N', $mask);
# use binary math to mask out net and host parts
$net = $addr & $mask;
$host = $addr & ~$mask; # ~$m = complement of mask (binary NOT)
# convert to "string" form
$net = pack('N', $net);
$host = pack('N', $host);
# convert to ASCII dotted-quad notation
$host = inet_ntoa($host);
$net = inet_ntoa($net);
# survey says...
print ("net : $net\n");
print ("host: $host\n");
Is that even close to what you were thinking of?
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Jason Stephenson <[EMAIL PROTECTED]> writes: > I'd suggest looking up how to configure VLANs on whatever you're > using for a router.--I know you mentioned a FreeBSD firewall > earlier. You must have missed the part where I said "we don't have a router", "we're migrating to a comletely new network", and, most importantly: "Ultimately, the ability to support "network addition" using something wacky like a /19 is entirely my own intellectual curiosity" :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Errr, no, just the opposite actually. Trying to *prevent* routing from a very existent router :) Sounds to me like what you really need is a router with VLAN capability. If I understand correctly, it sounds like you're trying to implement VLANs. Your setup actually sounds very similar to something that we're designing for all the libraries in our consortium. Right now, each site has a Class C (/24) on a 10.10.*. In the near future, we plan to implement each site having a Class B (/16) with different class Cs for each VLAN. For example, if a site is now on 10.10.32.0, it will move to 10.32.0.0 with something like 10.32.0.0/24 reserved for network equipment, 10.32.10.0/24 for the staff, 10.32.20.0/24 for the public, 10.32.30.0/24 for staff wireless, 10.32.40.0/24 for public wireless, etc.--The Dracut Public Library will be our first test case, since they're moving (back) into their renovated building next month. Without VLANs setup in the router, I can't imagine how that would work to prevent traffic among the various 10.32.0.0 "subnets." I suppose you could simulate it with some really complicated routing rules. At this point, my knowledge on the matter of networking begins to recede into nothingness. I can set up a simple Linux or *BSD router/firewall. I can do the math (poorly, but that's what computers are for). I can even use the socket() interface, but configuring fancy-shmancy, complicated network topologies is beyond my current abilities. I didn't design the above mentioned topology, nor did I figure out the configuration in the Cisco routers that we buy. However, I'm promised by our contractor that they'll show me enough so I can break things. ;) Long story made slightly longer, I'd suggest looking up how to configure VLANs on whatever you're using for a router.--I know you mentioned a FreeBSD firewall earlier. Cheers, Jason "Can't-the-network-for-the-wires" Stephenson ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Jason Stephenson <[EMAIL PROTECTED]> writes: It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Err, you've got the IP addresses wrong. It's 10.32.0.0/16, but segmented on a /19 boundary. I need to be able to calculate the "next" network, which for 10.32.0.0/19, would be 10.64.0.0/19, then take the host portion and "add" it to this new network such that any given host has the same host portion on all networks it may exist on. Doesn't matter. I got the network address wrong, too. ;) You want to interpolate the address of one host to another network, is that it? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: > On 3/28/06, Paul Lussier <[EMAIL PROTECTED]> wrote: >> If you really want the long convoluted discussion, I'll be glad to >> post it, I just figured no on would care. > > Well, everyone here knows *I* thrive on long, convoluted > discussions. I'm also curious if you're trying to route packets > through a non-existant gateway again. ;-) Errr, no, just the opposite actually. Trying to *prevent* routing from a very existent router :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes: > Well... okay... but it's the *why* that makes me wonder. :) > > I hope it's something interesting, and not just that he's trying to > say that he's been assigned the addresses in the range 10.0.32.0/19 on > the 10.0.0.0/16 network. That would be *so* boring. :) Well, since you've asked, I'm sure you'll regret it :) I'll try to be as brief and concise, yet clear as possible. It's confusing. We have no internal router. Just a legacy BSD box acting as a firewall. The internal network, for there really is only one, is 10.0.0.0/16. When it was set up, the 10.0.0 space was allocated along CIDR boundaries on the premise that someday we would have a router to separate un-like network traffic. As a result, we have something like this: Address/CIDR block| Function | Address Range Defined -- 10.0.0/22 | Dev/infrastructure servers | 10.0.0.0 - 10.0.3.255 10.0.4/22 | Mgmt/admin desktops, Mac laptops | 10.0.4.0 - 10.0.7.255 10.0.8/22 | Dev desktops | 10.0.8.0 - 10.0.11.255 10.0.12/24| Network hardware | 10.0.12.0 - 10.0.12.255 10.0.13/24| Printers | 10.0.13.0 - 10.0.13.255 10.0.14/24| MS-OS systems| 10.0.14.0 - 10.0.14.255 10.0.32/19| Dev lab systems | 10.0.32.0 - 10.0.63.255 This allocates a generous portion of addresses to various uses, and, if need be, subdivide based on /24 boundaries if we wanted to. The 10.0.32/19 is an interesting beast. The systems which live on it have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 based address (currently restricted to 10.0.33/24 for some reason?!), and a secondary eth1 which has a primary address of 10.106.XX.YY where XX.YY are the same as the 10.0.XX.YY, and where XX is currently always 33. i.e. host 10.0.33.124 has an eth1 IP of 10.106.33.124. Here's the *really* confusing part. Every system's eth1 *also* has 10 virtual/alias IPs of 10.[96-105].XX.YY. If you recall, I mentioned not having a router. Have I mentioned that the number of hosts in the 10.33/16 range is somewhere around 300, with another 50-100 being added in the next 2 months? :) Both NICs in all systems are essentially on one ethernet network! At any given time, these hosts can have both eth0 and eth1 up, plus any number of the 10 alias IPs up. We are actually about to cut over to a new network configuration this week. However, as the saying goes, "There's nothing more permanent than a temporary solution." and dev has basically evolved their testing infrastructure to *require* this flat network scheme. I'm currently testing things to make sure "nothing breaks" in the transition. One of the things our product does is look at the list of currently configured interfaces, take the "highest" IP and "add 1" to the network portion to obtain a new IP on a different network, but retaining the host portion of the IP. Basically, there's a multi-host negotiation which takes place and figures out a "back-channel" to communicate over. Since name resolution is not possible either via DNS, /etc/hosts, or other means, the only reliable means any two hosts have of reliably talking to each other is making sure that any given host keeps the same host portion of it's IP address on all networks. Does this help clarify things? Ultimately, the ability to support "network addition" using something wacky like a /19 is entirely my own intellectual curiosity, since in-house everything is on a /16 making it trivial. But it's one of those problems I can neither figure out, nor let go of :) As someone said to me yesterday, "IP addresses were never designed to be manipulated, merely assigned and used!" :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Jason Stephenson <[EMAIL PROTECTED]> writes: > It seems to me that the answer is that your IP addresses are limited > to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the > network address and 10.255.255.255 being the broadcast address, no? Err, you've got the IP addresses wrong. It's 10.32.0.0/16, but segmented on a /19 boundary. I need to be able to calculate the "next" network, which for 10.32.0.0/19, would be 10.64.0.0/19, then take the host portion and "add" it to this new network such that any given host has the same host portion on all networks it may exist on. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Jason Stephenson <[EMAIL PROTECTED]> wrote: > Of course, after looking back through the thread, I see Ben has already > pretty much answered the above. ;) "Repetition is the very soul of the net." -- from alt.config > Paul is using a network that is restricted to using a /19 netmask for > addressing, but it is really using a /16 when configured. So, he wants > to limit address to 10.0.32.0/19 but needs to configure broadcast and > network addresses for 10.0.32.0/16. Why he needs to do that, I have no > idea and wouldn't need to know. ;) Well... okay... but it's the *why* that makes me wonder. :) I hope it's something interesting, and not just that he's trying to say that he's been assigned the addresses in the range 10.0.32.0/19 on the 10.0.0.0/16 network. That would be *so* boring. :) > It seems to me that the answer is that your IP addresses are limited to > the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network > address and 10.255.255.255 being the broadcast address, no? Well, /16 means the first two octets are the network portion and the last two octets are the host portion. So the broadcast address (with CIDR) would be 10.0.255.255. Of course, 10.0.32.0/16 would normally be written 10.0.0.0/16, because, again, the third octet is part of the host portion. The host portion is really irrelevant when talking about network numbers. Convention says we fill the host portion with zeros. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Paul Lussier <[EMAIL PROTECTED]> wrote:
> If you really want the long convoluted discussion, I'll be glad to
> post it, I just figured no on would care.
Well, everyone here knows *I* thrive on long, convoluted
discussions. I'm also curious if you're trying to route packets
through a non-existant gateway again. ;-)
>> perl -we '$a = inet_addr("192.0.2.42");'
>>
>> but it complained that inet_addr is not defined.
>
> You likely need to use -MSocket, and then figure out which of the
> correct functions in there are analogous to inet_addr. The ones which
> leap to mind are inet_ntoa and inet_aton. There doesn't seem to be an
> inet_addr.
Hmmm Well, I just tried that quickly, but it looks like Perl's
inet_aton() function results in something that Perl thinks is a
string, not a long integer. (Probably because inet_aton() is defined
in terms of a pointer to character(s), in typical C fashion.) I don't
know how to tell Perl to treat the result as the integer it is (so I
can do binary operations on it).
Or maybe I'm using it wrong.
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Python <[EMAIL PROTECTED]> writes: Would it help to convert to 32-bit integers? I might. I'll try that. It will definitely help. If you get the "netmask" and address both in 32-bit integers, then calculating the network and broadcast addresses is very straightforward. Here's some sample code: network = address & netmask; broadcast = address | ~netmask; The above is C, but should work in Perl, too. Of course, after looking back through the thread, I see Ben has already pretty much answered the above. ;) I think I understand the arithmetic. I do not really understand what you are trying to do. That's okay, neither do I ;) (If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Of course, I also often misunderstimate the intellectual curiosity of fellow geeks :) I think Paul explained it pretty well in his first post. Let me explain to see if I really understand. Paul is using a network that is restricted to using a /19 netmask for addressing, but it is really using a /16 when configured. So, he wants to limit address to 10.0.32.0/19 but needs to configure broadcast and network addresses for 10.0.32.0/16. Why he needs to do that, I have no idea and wouldn't need to know. ;) Ben's previous message pretty much explains how to solve this. It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Cheers, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
"Ben Scott" <[EMAIL PROTECTED]> writes:
> I tried
>
> perl -we '$a = inet_addr("192.0.2.42");'
>
> but it complained that inet_addr is not defined. I suspect there's a
> module somewhere you need to pull in. Hopefully this is enough to get
> you started.
You likely need to use -MSocket, and then figure out which of the
correct functions in there are analogous to inet_addr. The ones which
leap to mind are inet_ntoa and inet_aton. There doesn't seem to be an
inet_addr.
--
Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Python <[EMAIL PROTECTED]> writes: > Would it help to convert to 32-bit integers? I might. I'll try that. > I think I understand the arithmetic. I do not really understand what > you are trying to do. That's okay, neither do I ;) (If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Of course, I also often misunderstimate the intellectual curiosity of fellow geeks :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/27/06, Paul Lussier <[EMAIL PROTECTED]> wrote:
> I'm stumped. I've got a network address space of 10.0.32/19. How
> ever, this space is carved up using a /16 netmask.
HUH?
> Given an address, say 10.0.33.189, I want to get the "network" and
> "host" portion of the address.
(1) Red Hat provides a nifty utility called "ipcalc" that will do
that for you. E.g.:
$ ipcalc -b -m -n -p 10.0.33.189/19
NETMASK=255.255.224.0
PREFIX=19
BROADCAST=10.0.63.255
NETWORK=10.0.32.0
$
(2) I find it's a lot easier to conceptualize this stuff if you
write it out in binary notation (view using a fixed-width font):
/19 = 255.255.224.0
010.000.033.189 = 1010 0011 1001
255.255.224.000 = 1110
Net portion = 1010 0010
Node portion= 0001 1001
(3) You mentioned Perl, but this is the same in most programming
languages: It's simple binary arithmetic and Boolean logic. All you
need are AND and NOT (complement). The trickier part is usually
converting from dotted-quad notation to binary storage. Fortunately,
Unix provides a function for that: inet_addr(2). C code looks like
this:
/* includes */
#include
#include
#include
#include
/* main program */
int main() {
/* variables */
unsigned int a; /* address */
unsigned int m; /* mask */
unsigned int n; /* node */
/* get address and mask, in network byte order */
a = inet_addr("192.0.2.42");
m = inet_addr("255.255.255.0");
/* find node portion by AND'ing with complement of net-mask */
n = a & (~m);
/* convert to host byte order */
n = ntohl(n);
/* print result as decimal integer */
printf("node=%d\n", n);
}
I tried
perl -we '$a = inet_addr("192.0.2.42");'
but it complained that inet_addr is not defined. I suspect there's a
module somewhere you need to pull in. Hopefully this is enough to get
you started.
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Mon, 2006-03-27 at 14:25 -0500, Paul Lussier wrote:
> Hi all,
>
> I'm stumped. I've got a network address space of 10.0.32/19. How
> ever, this space is carved up using a /16 netmask. In otherwords, the
> /19 netmask was simply used to *allocate* the space from 10.0.32.0 to
> 10.0.63.255, but we actually *use* the space with a /16 netmask (yes,
> this means that 10.0.8.10 is in the *same* physical network as
> 10.0.33.93!).
>
> Given an address, say 10.0.33.189, I want to get the "network" and
> "host" portion of the address. given that I'm really on a /16, it's
> fairly easy to split the IP at 10.0 and 33.189. However, I want to be
> able to do the same thing on the /19 as well. Once I have the network
> and host portions of the address, I need to increment the network
> portion by 1 block, then re-apply the host portion.
>
> For example, given the address 10.0.33.189/16:
>
> Network = 10.0 Host = 33.189
>+ 1
> -
> 10.1 + $HOST = 10.1.33.189
Would it help to convert to 32-bit integers?
When you add 1 here, you are really adding 2 ** 17. Your host mask is
int('1' * 16, 2)
So newIP = oldIP + 2 ** 17
newhost = newIP & hostmask
>
> And, given the address 10.0.33.189/19:
With a /19, you are adding 2**14
hostmask = int('1' * 13, 2)
Converting a.b.c.d (base 256) to integer is left as an exercise for the
reader. Perhaps you do not really care about the host mask. You can
simply convert the newIP back to base-256 notation.
I think I understand the arithmetic. I do not really understand what
you are trying to do.
>
> Network = 10.0.32 Host = 1.189
> + 1
> -
> 10.0.64 + $HOST = 10.1.65.189
>
> And, given the address 10.0.35.189/19:
> Network = 10.0.32 Host = 3.189
> + 1
> -
> 10.0.64 + $HOST = 10.1.67.189
>
> Getting the "next" network block isn't too tough, Net::Netmask does
> that for me. What I can't quite figure out is how to get the host
> portion, and then add it to the new network portion. For a classful
> address it's fairly simple, for CIDR address, not so much...
>
> All ideas are welcome and appreciated :)
>
> Thanks,
--
Lloyd Kvam
Venix Corp
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
Ben Scott wrote: The feeling I have is that Python has only started to get "mainstream attention" in the past few years, while Perl became popular sooner. If true, one wonders why. And if true, that might also account for some of the "buzz" around Python; Perl isn't as "interesting", being more established. It might also be that Perl is seen more as a "boring every-day problem solver". Perl leveraged a lot from shell scripting; for someone already proficient in ksh, awk, and sed, it was extremely simple to transition to perl. Essentially, you didn't have to start from scratch; perl felt like the same old familiar shell scripting, minus the pain of wrestling with awk and sed. -- John Abreau / Executive Director, Boston Linux & Unix ICQ 28611923 / AIM abreauj / JABBER [EMAIL PROTECTED] / YAHOO abreauj Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
On 3/17/06, Ted Roche <[EMAIL PROTECTED]> wrote: >> Nor did I take it as such. And I was merely observing that, though >> the languages are both roughly the same age, Perl has significantly >> more mind-share than Python. > > OTOH, other development circles I hang out in are all abuzz about > Python and Ruby. Perl just sort of "is". Lots of *innovative* things > seems to be showing up in Python. The feeling I have is that Python has only started to get "mainstream attention" in the past few years, while Perl became popular sooner. If true, one wonders why. And if true, that might also account for some of the "buzz" around Python; Perl isn't as "interesting", being more established. It might also be that Perl is seen more as a "boring every-day problem solver". Do note that the objective factual content of the above paragraph is zero. :) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
On Fri, Mar 17, 2006 at 12:56:13PM -0500, Drew Van Zandt wrote: > Google: Python vs. Perl Well Python wins, of course. Google uses Python in way more places than it uses Perl... Oh, you probably were using Google as a verb, and not a noun... -- Christopher Schmidt Web Developer ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
Google: Python vs. Perl Of course python is also a normal English-language word... --DTVZ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
> It depends upon the minds you're citing. Google cites 290 million > hits on Python versus 365 million on Perl, so you could argue > that's an edge or around a 4:5 ratio. Possibly. Of course, those stats might also be an indication that Perl is (or "many Perl programs are") so much more confusing than Python that it results in that many millions more desperate WWW searches for help in understanding it.;-> N.B. I'm just fanning the flames since I don't know either language... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
Dan Coutu <[EMAIL PROTECTED]> writes: > Piece of cake. You need to use the FindBin module that is included in > the default Perl distribution. Do this: > > #!/usr/bin/perl > use FindBin qw($Bin); > use lib "$Bin"; > use myinclude; > > This assumes that your module is named myinclude.pm and is in the same > directory as your perl script. I was just about to make this same recommendation. We've got hundreds of thousands of lines of perl code here at work, and this is where I first discovered the FindBin module. We use it extensively here, and probably wouldn't be able to do things nearly as easily without it. Almost every script we write has: use FindBin; use lib "/build/perl/lastrun/lib"; use lib "$FindBin::Bin/../../../perl/lib"; use lib $FindBin::Bin; It's really nice to not have to worry about your modules not being found :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On 12/5/05, Dan Coutu <[EMAIL PROTECTED]> wrote: > use FindBin qw($Bin); > use lib "$Bin"; > use myinclude; all of my perl code does basically this, but I stick things in a lib directory: /some/directory/myapp /some/directory/myapp/lib so the use lib line above would turn into use lib "$Bin/lib"; makes things a little easier to manage. -- Jeff Macdonald Ayer, MA ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On 12/5/05, Cole Tuininga <[EMAIL PROTECTED]> wrote: On Mon, 2005-12-05 at 15:59 -0500, Thomas Charron wrote:> use lib '.';Doesn't this assume you're executing the script from its own directory? In other words, wouldn't this break if I did something like:../otherpath/script.pl Yeppers.. ;-) It was a quick reply, didn't have time to fully explain it. But it's all in the use lib line. ;-) Thomas
Re: Perl include question
Cole Tuininga writes:
> I have a module (call it MyMod.pm) that I want to use in a program, but
> I can't install it in with the rest of the perl libraries. For reasons
> that are too boring to get into, the only guarantee I have is that it
> will be in the same directory as the executable script.
>
> How can I set up my include path (within the perl script) to make sure
> that the directory of the executable is in the include path? I can't
> hard code it because the location might be different on different
> machines (different mount points).
Try this:
#!/usr/bin/perl
BEGIN {
$dirname = $0;
$dirname =~ s#(.*/).*#$1#;
eval "use lib qw($dirname)";
}
use MyMod;
Hope this helps,
--kevin
--
GnuPG ID: B280F24E
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On Mon, 2005-12-05 at 15:59 -0500, Thomas Charron wrote: > use lib '.'; > > Thomas > Note that this will use your current directory as the place it looks for your module. The current directory would happen to depend on wherever you happen to have last done a cd to. That may not be what you really want. Chances you really want the module to be in the same directory as the perl script itself, or a directory relative to it. For that FindBin is the way to go. Dan > On 12/5/05, Cole Tuininga <[EMAIL PROTECTED]> wrote: > How can I set up my include path (within the perl script) to > make sure > that the directory of the executable is in the include > path? I can't > hard code it because the location might be different on > different > machines (different mount points). ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On Mon, 2005-12-05 at 15:59 -0500, Thomas Charron wrote: > use lib '.'; Doesn't this assume you're executing the script from its own directory? In other words, wouldn't this break if I did something like: ../otherpath/script.pl -- "The best firewall is a pair of wire cutters." -Unknown, from the net Cole Tuininga Lead Developer Code Energy, Inc [EMAIL PROTECTED] PGP Key ID: 0x43E5755D ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On Mon, 2005-12-05 at 15:25 -0500, Cole Tuininga wrote: > How can I set up my include path (within the perl script) to make sure > that the directory of the executable is in the include path? I can't > hard code it because the location might be different on different > machines (different mount points). > Piece of cake. You need to use the FindBin module that is included in the default Perl distribution. Do this: #!/usr/bin/perl use FindBin qw($Bin); use lib "$Bin"; use myinclude; This assumes that your module is named myinclude.pm and is in the same directory as your perl script. For more details use "perldoc FindBin" on the command line. Dan ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
use lib '.'; Thomas On 12/5/05, Cole Tuininga <[EMAIL PROTECTED]> wrote: How can I set up my include path (within the perl script) to make surethat the directory of the executable is in the include path? I can't hard code it because the location might be different on differentmachines (different mount points).
Re: Perl help
On Wed, Jul 23, 2003 at 08:18:55AM -0400, Kevin D. Clark <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > What's the relationship between Perl and C99? > > I don't think that there is a strong relationship. The Perl source > code is amazingly portable; it runs on well over 100 platforms. Most > of these platforms probably aren't C99 conformant, and so the Perl > source doesn't depend on C99 features. > > Perl could be enhanced to support these features on C99 > conformant platforms, probably most easily by writing a module. I mentioned the C99 standard as an international standard for C code that I suspected most languages printf routines aim to match. I was just trying to get more detail on a specfication for printf. -- Bob Bell <[EMAIL PROTECTED]> - "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams, author of _A Hitchhiker's Guide to the Galaxy_ ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
[EMAIL PROTECTED] writes: > What's the relationship between Perl and C99? I don't think that there is a strong relationship. The Perl source code is amazingly portable; it runs on well over 100 platforms. Most of these platforms probably aren't C99 conformant, and so the Perl source doesn't depend on C99 features. Perl could be enhanced to support these features on C99 conformant platforms, probably most easily by writing a module. Regards, --kevin -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Bob Bell <[EMAIL PROTECTED]> writes: > On Tue, Jul 22, 2003 at 05:13:03PM -0400, Kevin D. Clark <[EMAIL PROTECTED]> wrote: > > *3* Interesting fact of the day: Using binary, it is possible to > > exactly represent some numbers that cannot be exactly represented > > in base-10. > > Can you name such a number? This is un-intuitive to me, since 2 is > a factor of 10. I think I goofed: I didn't mean to write "base-2" above. Instead I meant to type "different base". If the statement is amended this way, then I'm sure that I'm correct. Damn. I need some sleep. --kevin -- "I'm on the bike and I go into a rage -- I shriek for about five seconds, I shake like mad, my eyes kind of bulge, and I'd never quit. That's heart. That's soul. That's guts" -- Lance Armstrong ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
What's the relationship between Perl and C99? Some insight might be gained from man fesetround ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, Jul 22, 2003 at 05:13:03PM -0400, Kevin D. Clark <[EMAIL PROTECTED]> wrote: > *3* Interesting fact of the day: Using binary, it is possible to > exactly represent some numbers that cannot be exactly represented > in base-10. Can you name such a number? This is un-intuitive to me, since 2 is a factor of 10. -- Bob Bell <[EMAIL PROTECTED]> - "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams, author of _A Hitchhiker's Guide to the Galaxy_ ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, Jul 22, 2003 at 04:19:17PM -0400, Cole Tuininga <[EMAIL PROTECTED]> wrote:
> However, I'm extremely confused by the following:
>
> [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.565 )'
> 0.56
>
> Can anybody explain why this is not rounding up? Thanks in advance...
First of all, I don't know why the code isn't simply:
$ perl -e 'printf("%.2f\n", 0.565)'
0.56
or why perl necessarily needs to be part of the solution:
$ printf "%.2f\n" 0.565
0.56
[ The printf command is part of the Single Unix Spec V2 (aka UNIX98) ]
I dug around in the C99 standard, and couldnt't find this referenced
anywhere. Additionally, I tried playing with more precision, and
turned up the following:
$ perl -e 'printf "%.19f -> %.2f\n", $_, $_ for qw/0.005 0.015 0.025 0.035 0.045/'
0.0050001 -> 0.01
0.0149990 -> 0.01
0.0250010 -> 0.03
0.0350030 -> 0.04
0.0449980 -> 0.04
So I think it's all about the precision of the number as stored as in
its binary representation.
--
Bob Bell <[EMAIL PROTECTED]>
-
"Testing shows the presence, not the absence, of bugs."
-- Edsger W. Dijkstra, University of Texas
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Stephen Ryan <[EMAIL PROTECTED]> writes: > Aha! Google for "round to even" -- it's an IEEE floating point > computation rule. Note that many systems *can* do IEEE floating point, but by default don't, since using the native floating point implementation can yield better performance. Regards, --kevin -- "I'm on the bike and I go into a rage -- I shriek for about five seconds, I shake like mad, my eyes kind of bulge, and I'd never quit. That's heart. That's soul. That's guts" -- Lance Armstrong ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Cole Tuininga <[EMAIL PROTECTED]> writes: > Got a perl question for y'all. I rarely have to do anything with perl, That's too bad. > and I'm sure perl has a good reason for behaving like the following, but > heck if I can figure it out. > > The perl cookbook suggestions using sprintf for rounding floats. This > seemingly works fine: > > [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.562 )' > 0.56 > [EMAIL PROTECTED]: perl -e 'print sprintf( "%.2f\n", 0.567 )' > 0.57 > > However, I'm extremely confused by the following: > > [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.565 )' > 0.56 > > Can anybody explain why this is not rounding up? Thanks in advance... The problem is is that you (The Human) see 0.565 as being an exact floating point number. Perl, running on The Binary Computer, sees 0.565 as being a character string. When you implicitly decide to use "0.565" as a number *1*, Perl, and the underlying system, makes an effort to convert this character string to the CPU's native floating representation. THIS IS NOT AN EXACT PROCESS *2* *3*. Subsequently, when you try to print out the number, and you specify to sprintf() that you want rounding to occur, it isn't clear what sprintf() should do in this case -- round up or round down? Either choice would be reasonable. There are many methods of doing rounding, and nearly all of these are imcompatable. If rounding is very important to your application, then you really need to write your own rounding function -- the system can't do it for you. *4* OBTW, your problem isn't specific to Perl. Perl just uses the underlying system to do all of the work for you. C, C++, and yes, even Python exhibit this behavior as well. Regards, --kevin *1* You are implicitly using floating point, BTW. *2* WORSE, you might be lulled into the belief that this is an exact process, since if you attempt to convert this floating point number to a string with a certain degree of precision, you'll seem to get your original number back. *3* Interesting fact of the day: Using binary, it is possible to exactly represent some numbers that cannot be exactly represented in base-10. *4* I'll be you can find a Math:: library that does what you think is the right thing here. Perhaps try Math::FixedPrecision . -- "I'm on the bike and I go into a rage -- I shriek for about five seconds, I shake like mad, my eyes kind of bulge, and I'd never quit. That's heart. That's soul. That's guts" -- Lance Armstrong ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, 2003-07-22 at 16:41, Stephen Ryan wrote: > On Tue, 2003-07-22 at 16:36, Erik Price wrote: > > Cole Tuininga wrote: > > > Got a perl question for y'all. I rarely have to do anything with perl, > > > and I'm sure perl has a good reason for behaving like the following, but > > > heck if I can figure it out. > > > > > > The perl cookbook suggestions using sprintf for rounding floats. This > > > seemingly works fine: > > > > > > [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.562 )' > > > 0.56 > > > [EMAIL PROTECTED]: perl -e 'print sprintf( "%.2f\n", 0.567 )' > > > 0.57 > > > > > > However, I'm extremely confused by the following: > > > > > > [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.565 )' > > > 0.56 > > > > I don't have an answer, Cole, but the same happens in Python and I'd bet > > in C as well -- must be a convention of the printf routines: > > > > Python 2.2.2 (#1, Mar 9 2003, 08:18:26) > > [GCC 3.2 20020927 (prerelease)] on cygwin > > Type "help", "copyright", "credits" or "license" for more information. > > >>> print "%.2f\n" % 0.562 > > 0.56 > > > > >>> print "%.2f\n" % 0.567 > > 0.57 > > > > >>> print "%.2f\n" % 0.565 > > 0.56 > > > Aha! Google for "round to even" -- it's an IEEE floating point > computation rule. Errm. I take it back. $ perl -e 'print sprintf( "%.2f\n", 0.575 )' 0.57 Dunno what's up with that. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Erik Price said: > > Cole Tuininga wrote: >> Got a perl question for y'all. I rarely have to do anything with >> perl, and I'm sure perl has a good reason for behaving like the >> following, but heck if I can figure it out. >> >> The perl cookbook suggestions using sprintf for rounding floats. This >> seemingly works fine: >> >> [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.562 )' >> 0.56 >> [EMAIL PROTECTED]: perl -e 'print sprintf( "%.2f\n", 0.567 )' >> 0.57 >> >> However, I'm extremely confused by the following: >> >> [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.565 )' >> 0.56 > > I don't have an answer, Cole, but the same happens in Python and I'd bet > in C as well -- must be a convention of the printf routines: > > Python 2.2.2 (#1, Mar 9 2003, 08:18:26) > [GCC 3.2 20020927 (prerelease)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>> print "%.2f\n" % 0.562 > 0.56 > > >>> print "%.2f\n" % 0.567 > 0.57 > > >>> print "%.2f\n" % 0.565 > 0.56 It's kind of a kludge, but perhaps adding some very small value such as 0.1 just prior to the rounding will get the result you want? [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.56501 )' 0.57 -- Bill Mullen [EMAIL PROTECTED] MA, USA RLU #270075 MDK 8.1 & 9.0 "Giving money and power to the government is like giving whiskey and car keys to teenage boys." - P.J. O'Rourke ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
RE: Perl help
> Can anybody explain why this is not rounding up? Thanks in advance... It view .5 as a round down situation, I have seen it in other languages, too... - bryan ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, 2003-07-22 at 16:36, Erik Price wrote: > Cole Tuininga wrote: > > Got a perl question for y'all. I rarely have to do anything with perl, > > and I'm sure perl has a good reason for behaving like the following, but > > heck if I can figure it out. > > > > The perl cookbook suggestions using sprintf for rounding floats. This > > seemingly works fine: > > > > [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.562 )' > > 0.56 > > [EMAIL PROTECTED]: perl -e 'print sprintf( "%.2f\n", 0.567 )' > > 0.57 > > > > However, I'm extremely confused by the following: > > > > [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.565 )' > > 0.56 > > I don't have an answer, Cole, but the same happens in Python and I'd bet > in C as well -- must be a convention of the printf routines: > > Python 2.2.2 (#1, Mar 9 2003, 08:18:26) > [GCC 3.2 20020927 (prerelease)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>> print "%.2f\n" % 0.562 > 0.56 > > >>> print "%.2f\n" % 0.567 > 0.57 > > >>> print "%.2f\n" % 0.565 > 0.56 Aha! Google for "round to even" -- it's an IEEE floating point computation rule. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Cole Tuininga wrote: Got a perl question for y'all. I rarely have to do anything with perl, and I'm sure perl has a good reason for behaving like the following, but heck if I can figure it out. The perl cookbook suggestions using sprintf for rounding floats. This seemingly works fine: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.562 )' 0.56 [EMAIL PROTECTED]: perl -e 'print sprintf( "%.2f\n", 0.567 )' 0.57 However, I'm extremely confused by the following: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( "%.2f\n", 0.565 )' 0.56 I don't have an answer, Cole, but the same happens in Python and I'd bet in C as well -- must be a convention of the printf routines: Python 2.2.2 (#1, Mar 9 2003, 08:18:26) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> print "%.2f\n" % 0.562 0.56 >>> print "%.2f\n" % 0.567 0.57 >>> print "%.2f\n" % 0.565 0.56 Erik ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Thu, 22 Aug 2002 08:56:37 EDT "Jerry Feldman" said: >Burger King's point of Sale system in the early 1970s was a PDP-8M with 4 >attached registers. No disk, no paper tape, core memory. For the modem, we >had to time the 1200 baud with timing loops and send a bit at a time. No >UART. We also had to strike the hammers on the printer drum. Keyboard >required to reads (row and column). If the system crashed, a service guy >had to come in, plug in the paper tape board, and reload the program. You know, I just heard someone complaining that the quaility of "service" people has taken a drastic drop in the last 20-30 years. I guess if, to work for Burger King inthe 1970s you needed to be able to operate a PDP-8 class machine you'd have to be a whole lot smarter than those "touch screen monkeys" they have now-a-days, which explains why QoS at the burger joints has gone down hill ;) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Thu, 22 Aug 2002 09:02:50 EDT Jon Hall said: >O.K.: > >First you toggle in the BIN loader. On the PDP-8 this was seventeen >twelve-bit instructions, so you have to flip (and get ABSOLUTELY CORRECT) >204 switches, and this was AFTER you toggled in the correct starting address. Okay, I've got to ask. Anyone here actually have this 204 switch-toggling sequence *still* memorized after all these years? ;) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Thu, 22 Aug 2002 00:12:36 EDT "Bayard R. Coolidge" said: >[EMAIL PROTECTED] asked: > was Unix ever developed on any of those? >(meaning the 12-bit PDP-8/PDP-12 architectures) > >AFAIK, no. I believe that the original development was >on some PDP-11's (11/45's?) that Bell Labs had at the time. I thought they were PDP-7s, no? If so, then they wouldn't need to back-port to the 8, would they? Though for some reason, I thought that the 7 and 11 were closer in architecture and that the 8 was totally different than anything else. >Those, of course, are 16-bit machines. But, I don't ever >hearing about any "back-porting" to the PDP-8's. At the >time, it would have been a real PITA, because the I/O >architectures were totally different. Different from the 7 *and* 11, or just different from the 11? -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Wed, 21 Aug 2002 19:30:45 EDT [EMAIL PROTECTED] said: > I'm just curious... was Unix ever developed on any of those? I was pretty >much under the impression that Unix assumes an 8-bit byte, but I don't >really have anything to back that up... It was originally *developed* on a PDP-7 if my memory banks are correctly ECC'ed :) I believe it was ported to the PDP-8 at one point, but I don't remember for sure. I can check my copy of "25 years w/ UNIX" tonight when I get home if you wish :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] said: > All this in 4K memory. Yeah, but Burger King was not selling as many hamburgers back in those days. :-) md -- = Jon "maddog" Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Actually, WRT: Burger King, the PDP-8 was located under the counter. The AMF service guys were equipped with a briefcase mounted paper tape reader, and a few other things including the board. The POS maintained inventory, hourly sales by product, cash control, as well as the normal POS functions. The data was transmitted to Miami every night. There was only a single day's storage available. 100% of the software was written in PDP-8 assembler (Sabre I believe). Program changes were uploaded as necessary. All this in 4K memory. On 22 Aug 2002 at 9:18, Hewitt Tech wrote: > Or alternatively the service person could load the appropriate diagnostic > into a machine and then carry the core memory module to the system that > needed to be diagnosed. This could be very useful when the system you needed > to repair was difficult to get at (sitting in a cramped closet, etc.). The > memory module was easier to get at then trying to plug in a peripheral and > it's controller. Once you had the core memory plugged into the system you > would load the starting address of the diagnostic and then hit the "run" > switch. > > -Alex > > P.S. Geez, I guess I am getting to be "older than dirt"! ;^) > > - Original Message - > From: "Jerry Feldman" <[EMAIL PROTECTED]> > To: "Greater NH Linux User Group" <[EMAIL PROTECTED]> > Sent: Thursday, August 22, 2002 8:56 AM > Subject: Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ] > > > > Discussed that last night at the BLU meeting. > > Many of the PDP-8s did not come with a ROM. To load the executive, you > > would key in the RIM(ReadInMode) loader on the front panel switches. The > > RIM loader was a very simple paper tape reader program whose purpose was > to > > read in the real paper tape loader. From there you could reload the PDP-8. > > > > Burger King's point of Sale system in the early 1970s was a PDP-8M with 4 > > attached registers. No disk, no paper tape, core memory. For the modem, we > > had to time the 1200 baud with timing loops and send a bit at a time. No > > UART. We also had to strike the hammers on the printer drum. Keyboard > > required to reads (row and column). If the system crashed, a service guy > > had to come in, plug in the paper tape board, and reload the program. > > On 22 Aug 2002 at 8:36, [EMAIL PROTECTED] wrote: > > > Okay, I have to ask: What's a "RIM loader"? > > > > -- > > Jerry Feldman <[EMAIL PROTECTED]> > > Associate Director > > Boston Linux and Unix user group > > http://www.blu.org PGP key id:C5061EA9 > > PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 > > > > ___ > > gnhlug-discuss mailing list > > [EMAIL PROTECTED] > > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss > > > -- Jerry Feldman <[EMAIL PROTECTED]> Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Or alternatively the service person could load the appropriate diagnostic into a machine and then carry the core memory module to the system that needed to be diagnosed. This could be very useful when the system you needed to repair was difficult to get at (sitting in a cramped closet, etc.). The memory module was easier to get at then trying to plug in a peripheral and it's controller. Once you had the core memory plugged into the system you would load the starting address of the diagnostic and then hit the "run" switch. -Alex P.S. Geez, I guess I am getting to be "older than dirt"! ;^) - Original Message - From: "Jerry Feldman" <[EMAIL PROTECTED]> To: "Greater NH Linux User Group" <[EMAIL PROTECTED]> Sent: Thursday, August 22, 2002 8:56 AM Subject: Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ] > Discussed that last night at the BLU meeting. > Many of the PDP-8s did not come with a ROM. To load the executive, you > would key in the RIM(ReadInMode) loader on the front panel switches. The > RIM loader was a very simple paper tape reader program whose purpose was to > read in the real paper tape loader. From there you could reload the PDP-8. > > Burger King's point of Sale system in the early 1970s was a PDP-8M with 4 > attached registers. No disk, no paper tape, core memory. For the modem, we > had to time the 1200 baud with timing loops and send a bit at a time. No > UART. We also had to strike the hammers on the printer drum. Keyboard > required to reads (row and column). If the system crashed, a service guy > had to come in, plug in the paper tape board, and reload the program. > On 22 Aug 2002 at 8:36, [EMAIL PROTECTED] wrote: > > Okay, I have to ask: What's a "RIM loader"? > > -- > Jerry Feldman <[EMAIL PROTECTED]> > Associate Director > Boston Linux and Unix user group > http://www.blu.org PGP key id:C5061EA9 > PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 > > ___ > gnhlug-discuss mailing list > [EMAIL PROTECTED] > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss > ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] said: > AFAIK, no. I believe that the original development was on some > PDP-11's (11/45's?) No, the original development was on a PDP-7, and in assembler. The second machine it ran on was a PDP-11, also in assembler. It was after that port that Dennis wrote "C", to make the next port easier. I think that for the most part he succeeded. [EMAIL PROTECTED] said: > Okay, I have to ask: What's a "RIM loader"? O.K.: First you toggle in the BIN loader. On the PDP-8 this was seventeen twelve-bit instructions, so you have to flip (and get ABSOLUTELY CORRECT) 204 switches, and this was AFTER you toggled in the correct starting address. That BIN loader then loaded in a paper tape that had the RIM loader on it, which (hopefully) stayed in memory to load in things like an Editor, Assembler and (eventually) your program. However, with only 4K words (and poor programming skills) you usually overwrote the RIM loader with your program bombing (er, ah) running, so you had to start ALL OVER AGAIN. Ah, the good old days. :-) md -- = Jon "maddog" Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Discussed that last night at the BLU meeting. Many of the PDP-8s did not come with a ROM. To load the executive, you would key in the RIM(ReadInMode) loader on the front panel switches. The RIM loader was a very simple paper tape reader program whose purpose was to read in the real paper tape loader. From there you could reload the PDP-8. Burger King's point of Sale system in the early 1970s was a PDP-8M with 4 attached registers. No disk, no paper tape, core memory. For the modem, we had to time the 1200 baud with timing loops and send a bit at a time. No UART. We also had to strike the hammers on the printer drum. Keyboard required to reads (row and column). If the system crashed, a service guy had to come in, plug in the paper tape board, and reload the program. On 22 Aug 2002 at 8:36, [EMAIL PROTECTED] wrote: > Okay, I have to ask: What's a "RIM loader"? -- Jerry Feldman <[EMAIL PROTECTED]> Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Thu, 22 Aug 2002, at 12:12am, Bayard R. Coolidge wrote: > Bayard, who tried, but failed to find his old copy of the > RIM loader... Okay, I have to ask: What's a "RIM loader"? -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] asked: >>> was Unix ever developed on any of those? (meaning the 12-bit PDP-8/PDP-12 architectures) AFAIK, no. I believe that the original development was on some PDP-11's (11/45's?) that Bell Labs had at the time. Those, of course, are 16-bit machines. But, I don't ever hearing about any "back-porting" to the PDP-8's. At the time, it would have been a real PITA, because the I/O architectures were totally different. Also, by the time that UNIX was more or less working well enough to distribute to its users, the PDP-8 was rapidly approaching end-of-life; DEC had jumped through some really wierd hoops to get it to address 128kb of memory, and it was clear that that was it. The PDP-11s, on the other hand, could do that much fairly easily and was obviously much more extendible. Much of the development in the mid-70's was to meet some interesting requirements that customers had voiced, and obviously some of those customers were running UNIX. HTH, Bayard, who tried, but failed to find his old copy of the RIM loader... ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Wed, 21 Aug 2002, at 6:44pm, Jon Hall wrote: > To throw a bit (pun un-intentional) more into this discussion, don't > assume that a "byte" was eight bits. The PDP-8, Linc-8 and PDP-12 for > instance, were all twelve bit words, broken down into two six-bit > characters. I'm just curious... was Unix ever developed on any of those? I was pretty much under the impression that Unix assumes an 8-bit byte, but I don't really have anything to back that up... -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
To throw a bit (pun un-intentional) more into this discussion, don't assume that a "byte" was eight bits. The PDP-8, Linc-8 and PDP-12 for instance, were all twelve bit words, broken down into two six-bit characters. Nevertheless, back in those days saving a few bits for every entry in a symbol table was worth the time and effort. md -- = Jon "maddog" Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Wed, 21 Aug 2002, at 2:52pm, Bill Freeman wrote: > The description is close. Radix 50 actually allows you to get three > characters into a 16 bit word (40*40*40 <= 65536), or 6 into a 32 bit > word. Ya know, I thought a gain of only one character (five characters, vs the four 8-bit bytes in a 32-bit word) seemed too small, but I didn't actually do the math. Hypothesis: Since "creat" is a system call, and system calls are often implemented "behind the scenes" by functions with an underscore prefix (i.e., "_creat"), that might explain where the sixth character went. This debate only goes to show why Ken Thompson might well believe that the biggest mistake he made was spelling "creat" without the trailing "e". :-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Mark Komarinski writes: > Good thing more colors other than green and amber were invented too. Newcommer! We only had black print on those cards and listings. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] writes: > Way back when 16 kilobytes was a lot of memory, a method for encoding five > characters into a single 32-bit machine word was developed. It was called > "Radix-50", or "RAD50". The 50 is octal, or 40 decimal. The character set > was 26 monocase letters, 10 digits, three special characters, and a null (a > total of 40). This encoding was used in the linkers of various DEC PDP > operating systems, which is where Unix was born. > > (That could, of course, be incorrect, but I did find references to > Radix-50/RAD50 in some old DEC migration documentation.) It was also known as "squoze code" around the M.I.T. AI lab. RAD50 may have originated at DEC, but I wouldn't bet either way. The description is close. Radix 50 actually allows you to get three characters into a 16 bit word (40*40*40 <= 65536), or 6 into a 32 bit word. 5 characters will actually fit into 27 bits (10240 being no greater than 134217728). That means that you can also have up to 5 bits of "flags", say, for symbol type, in the same (double 16 bit) word of your symbol table as that which stores the name. When it wasn't uncommon to have as little as 4k words (8k bytes) on your PDP-11/20, people really did care about bit twiddling. People writing in assembly language for such machines didn't seem to chaff at such symbol length restrictions. (Perhaps few of them could type, and short names were easier.) Linkers developed for use with assemblers were pressed into service for linking C because originally the C compiler produced assembly languagy, and the assembler was invoked on the output. Bill ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Wed, 21 Aug 2002, at 10:10am, [EMAIL PROTECTED] wrote: > Okay, I'll buy that, but why create a linker that only supports 5 > character function names? Okay, some Google searches eventually tracked down this explanation: Way back when 16 kilobytes was a lot of memory, a method for encoding five characters into a single 32-bit machine word was developed. It was called "Radix-50", or "RAD50". The 50 is octal, or 40 decimal. The character set was 26 monocase letters, 10 digits, three special characters, and a null (a total of 40). This encoding was used in the linkers of various DEC PDP operating systems, which is where Unix was born. (That could, of course, be incorrect, but I did find references to Radix-50/RAD50 in some old DEC migration documentation.) > I guess I don't fully understand the role of linkers, if this should be an > obvious thing :) A compiler/assembler turns source code into object code modules. Those modules are not working programs yet; they have symbolic names instead of addresses for variables and functions in many places. You then need to link the modules together, which includes replacing symbolic names with machine addresses everywhere. The output of the linking process is an executable program. Run-time dynamic linking makes things more complex. *hand wave* -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Good thing more colors other than green and amber were invented too. -Mark On Wed, Aug 21, 2002 at 11:00:10AM -0400, Andrew W. Gaunt wrote: > > Back in the early days of computers there weren't > as many characters to go around and folks had to > be very conservative with their use. Since then, more > have been pulled out of the ground so we can use > them more liberally. > > -- > __ > | 0|___||. Andrew Gaunt *nix Sys. Admin., etc. > _| _| : : } [EMAIL PROTECTED] - http://www-cde.mv.lucent.com/~quantum > -(O)-==-o\ [EMAIL PROTECTED] - http://www.gaunt.org ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Back in the early days of computers there weren't as many characters to go around and folks had to be very conservative with their use. Since then, more have been pulled out of the ground so we can use them more liberally. -- __ | 0|___||. Andrew Gaunt *nix Sys. Admin., etc. _| _| : : } [EMAIL PROTECTED] - http://www-cde.mv.lucent.com/~quantum -(O)-==-o\ [EMAIL PROTECTED] - http://www.gaunt.org [EMAIL PROTECTED] wrote: > > In a message dated: Tue, 20 Aug 2002 16:43:36 EDT > [EMAIL PROTECTED] said: > > > I believe it was Ken Thompson, and I believe the remark was intended to be > >humorous. Step back and ask: Why would he spell "create" as "creat" in the > >first place? If you are going to type five characters, you might as well > >type six. The reason it was spelled "creat" in the first place was the > >linked only supported five characters. That has caused much > >head-scratching, question-asking, and recompiling-due-to-typos; hence the > >remark about the spelling. > > Okay, I'll buy that, but why create a linker that only supports 5 > character function names? What was it which caused this scenario? > I guess I don't fully understand the role of linkers, if this should > be an obvious thing :) > -- > > Seeya, > Paul > -- > It may look like I'm just sitting here doing nothing, >but I'm really actively waiting for all my problems to go away. > > If you're not having fun, you're not doing it right! > > ___ > gnhlug-discuss mailing list > [EMAIL PROTECTED] > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 16:52:35 EDT
"Steven W. Orr" said:
>On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
>=>In a message dated: Tue, 20 Aug 2002 15:16:58 CDT
>=>Thomas Charron said:
>=>
>=>For example, in shell, the construct:
>=>
>=> cd /tmp && rm foo
>
>Whotchoo talkin 'bout Willis?
>
>cd == chdir is a builtin command. But point taken.
Okay, bad example :) How about:
PID=`ps -ef | grep foo | awk '{print $2}'`
kill -9 $PID
That's 4 sub-processes :)
>Actually, debugging bash isn't all that bad.
I'm not saying it can't be done, but...
>set -x
isn't the same as a debugger with break points, watches, etc.
>And there is a full blown
>debugger available for ksh with breakpoints and everything. :-)
Ooh, now *that's* cool! Thanks!
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 16:43:36 EDT [EMAIL PROTECTED] said: > I believe it was Ken Thompson, and I believe the remark was intended to be >humorous. Step back and ask: Why would he spell "create" as "creat" in the >first place? If you are going to type five characters, you might as well >type six. The reason it was spelled "creat" in the first place was the >linked only supported five characters. That has caused much >head-scratching, question-asking, and recompiling-due-to-typos; hence the >remark about the spelling. Okay, I'll buy that, but why create a linker that only supports 5 character function names? What was it which caused this scenario? I guess I don't fully understand the role of linkers, if this should be an obvious thing :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, [EMAIL PROTECTED] hath spake thusly: > Yet you complain about Perl being hard to learn and use, for the same > reasons, and not just for you, but for everyone? I absolutely said no such thing. Let's make this even simpler. Mike O'Donnell commented about finding the prospect of learning Perl daunting. I attempted to convey to the perlheads here who responded with incredulity that I too had the same reaction, attempted to learn it, found that learning *facile* use of it was more difficult than any other language I'd tried to learn. I then proceeded to attempt to explain why *I* found it that way, apparently to no one's satisfaction. Suffice it to say that the reasons don't much matter. Whatever the reason, that was my experience, and so I can sympathize with anyone who voices those kinds of opinions. I'm done with this topic. - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9YvRKdjdlQoHP510RAmxvAKCK63cngoBI1lKJMYC1IV7dK/+CMwCdHpEY DHiXcd02zX933Gi4VoyFNJQ= =gng9 -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Didn't you work with Grace Hopper :-) "Hewitt Tech" wrote: > You had "C"? All we had was assembler! You had assembler? All we had was > ones and zeros! You had ones and zeros? ... -- -- Gerald Feldman <[EMAIL PROTECTED]> Boston Computer Solutions and Consulting ICQ#156300 PGP Key ID:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
On Tue, 20 Aug 2002, at 12:37pm, Derek D. Martin wrote: [ Several paragraphs of completely irrelevant and bogus argument deleted. I will provide explicit debunking of said argument if so requested. ] > There are very few Unix commands whose names are completely > unintelligible, and learning them is much easier than learning the > difference between $^P and $^B. At least for me, and I suspect most > people. [ ... snip ... ] > Perhaps. But I have a very good grasp of regexp and that's definitely > not what *I* am talking about. Okay, so, you have no trouble understanding the Unix environment, which is inconsistent, obscure, and cryptic. You have no trouble with regular expressions, which have, arguably, the most cryptic syntax of any popular language construct, ever. Yet you complain about Perl being hard to learn and use, for the same reasons, and not just for you, but for everyone? That does not add up. Is Perl cryptic? Sure. So are many other things which *you have no problem with*, which was my point. I am willing to bet, dollars to donuts, that the real reason you find Unix "easy" while Perl is "hard" is that you use Unix every day, day in, and day out, while Perl is something you only dabble in. Of course, I cannot prove that assertion, but I ask you consider it as objectively as you can (if that is not a complete logical impossibility, which I rather suspect it is). On Tue, 20 Aug 2002, at 3:01pm, Derek D. Martin wrote: > - Perl "grew" rather than being designed. Its syntax is a > mish-mash of features from several other languages and/or utilities > all glued together, and as such sometimes seems to be inconsistent > with itself. Agreed. But, again, Unix is the same way, and so is MS-Windows, yet we have no problem telling people they can/should learn those. Why does Perl get singled out? > - Perl does some things which are commonly done in programming >languages very, very differently from the rest True, but irrelevant. Compare Python, C, and Scheme, and you'll get a far bigger diff. All programming languages are different. > - Perl has a lot of obscure features and syntax, like the so-called > "magic" variables, that don't lend themselves to readable code Marginal. Mechanisms are in place to eliminate the magic variable problem, because said magic variables are recognized as cryptic. What I find more telling is that, at least in my experience, few of those magic variables are needed in practice. I certainly rarely use them. It is like complaining about trigraphs in C. Yes, they are obscure and cryptic, but nobody uses them, so who cares? Can you give an example of anything *other* than the magic variable problem? I am starting to think you're just hung up on magic variables, the way some people get wedged on whitespace in Python. > - The people who write Perl by and large seem to prefer a style (if > you can call it that) that promotes neither code readability nor > education Can you back that up with any kind of real evidence? My personal theory on this is a bit different. There are people who like to write dense, terse, cryptic code. Perl, being the flexible beast that it is, lets those people do that to the extreme. So those people tend to gravitate to Perl. You see a lot more such code written in Perl, because Perl is the best tool to do it in -- a dubious distinction, I'll agree. However, just because there are a large number of hacks writing line-noise in Perl doesn't mean every Perl coder on the planet does it. I certainly don't find much of that stuff in the Camel books, other than deliberate instances of it. > For all its wiz-bang features that make many tasks which are difficult on > other languages much easier in perl, it lacks the ability to easily > manipulate data structures ... True, and a recognized problem, and one that is being worked on in Perl 6. However, I don't think anyone was suggesting that Perl is the universal fix to all programming problems. Perl excels at munching text, working with dynamic lists of flat data, and associative lookups (among other things). The tasks Perl does well are all tasks done frequently in computer programs as well. > But many of the features of Perl compound [the problem of reading other > people's code], making for naturally ugly code. I find that Perl often leads to naturally elegant code, when used properly. I have to wonder if your problem is just that you hang around too many lousy Perl hackers. :-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
You had "C"? All we had was assembler! You had assembler? All we had was ones and zeros! You had ones and zeros? ... -Alex - Original Message - From: "Jerry Feldman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 20, 2002 4:53 PM Subject: Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ] > I think you are correct. Create(2) is a system call. Linkage editors those > days were rather primitive. I think the name limit was either 7 or 8, but > external names in C were many times autoprefixed with __, such that creat > became __creat. > The C language had a limit of 8 characters for a variable name (K&R 2.1). > (Actually a name could be longer, but only the first 8 were significant). > I think the only other programmer on this list who might have been writing > C back then is my granduncle, Alex Hewitt ;-) > > On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: > > I believe it was Ken Thompson, and I believe the remark was intended to be > > humorous. Step back and ask: Why would he spell "create" as "creat" in the > > first place? If you are going to type five characters, you might as well > > type six. The reason it was spelled "creat" in the first place was the > > linked only supported five characters. That has caused much > > head-scratching, question-asking, and recompiling-due-to-typos; hence the > > remark about the spelling. > > -- > Jerry Feldman <[EMAIL PROTECTED]> > Associate Director > Boston Linux and Unix user group > http://www.blu.org PGP key id:C5061EA9 > PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 > > ___ > gnhlug-discuss mailing list > [EMAIL PROTECTED] > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss > ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, Jerry Feldman wrote: =>I think you are correct. Create(2) is a system call. Linkage editors those =>days were rather primitive. I think the name limit was either 7 or 8, but =>external names in C were many times autoprefixed with __, such that creat =>became __creat. =>The C language had a limit of 8 characters for a variable name (K&R 2.1). =>(Actually a name could be longer, but only the first 8 were significant). =>I think the only other programmer on this list who might have been writing =>C back then is my granduncle, Alex Hewitt ;-) => =>On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: =>> I believe it was Ken Thompson, and I believe the remark was intended to be =>> humorous. Step back and ask: Why would he spell "create" as "creat" in the =>> first place? If you are going to type five characters, you might as well =>> type six. The reason it was spelled "creat" in the first place was the =>> linked only supported five characters. That has caused much =>> head-scratching, question-asking, and recompiling-due-to-typos; hence the =>> remark about the spelling. I have to jump in with an old arcana of my own. I used to work at Data General during Soul of a New Machine days. Their AOS operating system actually had roots originating from earliest Unix. The deal there was that all external variables (by convention) were coded in uppercase. Why? Because sometimes we needed to assign values at linktime to symbols. This was done on the commandline. And the Data General Command Line Interface (CLI) was case insensitive. So if the symbol wasn't uppercase, then the linker would be monkeying with the wrong symbol. :-) -- -Time flies like the wind. Fruit flies like a banana. Stranger things have - -happened but none stranger than this. Does your driver's license say Organ -Donor?Black holes are where God divided by zero. Listen to me! We are all- -individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
I think you are correct. Create(2) is a system call. Linkage editors those days were rather primitive. I think the name limit was either 7 or 8, but external names in C were many times autoprefixed with __, such that creat became __creat. The C language had a limit of 8 characters for a variable name (K&R 2.1). (Actually a name could be longer, but only the first 8 were significant). I think the only other programmer on this list who might have been writing C back then is my granduncle, Alex Hewitt ;-) On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: > I believe it was Ken Thompson, and I believe the remark was intended to be > humorous. Step back and ask: Why would he spell "create" as "creat" in the > first place? If you are going to type five characters, you might as well > type six. The reason it was spelled "creat" in the first place was the > linked only supported five characters. That has caused much > head-scratching, question-asking, and recompiling-due-to-typos; hence the > remark about the spelling. -- Jerry Feldman <[EMAIL PROTECTED]> Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
