Another undoubtedly stupid question. 
Author Message
 Another undoubtedly stupid question.

How do I access the compiler along the lines of Python's eval/exec/compile
suite using Harlequin Dylan?

For reference, in case you're unfamiliar with Python, eval() is a function
which evaluates a string as a python expression; exec is a statement which
executes a string as a block of Python code; compile() is a function which
compiles a string into a code object for writing to disk or later execution.

(I understand languages like Smalltalk have this kind of access to the
compiler as well while the Lisp derivatives effectively integrate the
compiler into the language definition itself.)

--

          PGP Key: http://www.*-*-*.com/ ~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8



Sat, 17 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.


    Date: Tue, 01 Jun 1999 18:26:23 GMT

    How do I access the compiler along the lines of Python's eval/exec/compile
    suite using Harlequin Dylan?

You don't.  'eval' is not part of Dylan.

If you can explain what you are really trying to do, there may be
other solutions within Dylan.  Or the solution may be to use Lisp or
Python...

    For reference, in case you're unfamiliar with Python, eval() is a function
    which evaluates a string as a Python expression; exec is a statement which
    executes a string as a block of Python code; compile() is a function which
    compiles a string into a code object for writing to disk or later execution.



Sat, 17 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.

Quote:
>> How do I access the compiler along the lines of Python's
eval/exec/compile
>> suite using Harlequin Dylan?
> You don't.  'eval' is not part of Dylan.

Fair enough.

Quote:
> If you can explain what you are really trying to do,

I'm trying to feel out the boundaries of Dylan so I know what I can and
cannot commit to when writing software in it.  :-)

It's all part of being a major tinkerer, you see.  It's also why I "speak"
anywhere from a half-dozen to a dozen computer languages at least
semi-fluently at almost any moment in time (although the set of languages
changes as the years go by).

Quote:
> Or the solution may be to use Lisp or Python...

That is always an option.  (Well, except for the Lisp part.  I'm not a huge
fan of it and its derivatives.)

I'm not an advocate of having a woodworking toolbox with only a saw in it.
Why should I only use one tool in my computing toolbox?  As it so happens, I
tend to use Python for scripting, Lua for embedding, C++ for most of my
professional work (currently, at any rate) and Dylan when I can get away
with it.  That and a smattering of various assemblers gives me my current
toolkit (in terms of languages; libraries, etc. are another matter
entirely).

--

          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8



Sat, 17 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.


    Date: Tue, 01 Jun 1999 19:12:25 GMT

    That is always an option.  (Well, except for the Lisp part.  I'm not a huge
    fan of it and its derivatives.)

Oops, I guess that rules out Dylan!  :-)



Sat, 17 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.


Quote:
>> That is always an option.  (Well, except for the Lisp part.  I'm
>> not a huge fan of it and its derivatives.)
> Oops, I guess that rules out Dylan!  :-)

For dynamic compilation?  I thought we just got through that.  Dylan
doesn't have this as a language feature.
:-)

For clarification, however, replace "derivatives" with "look-alikes" (i.e.
Lisp, Scheme, etc.).

You're a funny man, Scott.  :-)

--

          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8



Sat, 17 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.

It shouldn't be too hard to write a simple evaluator in Dylan.
For instance, you could have a table that maps names (symbols)
to the functions you want to be callable and then use apply
to call them.  The evaluator would also have to handle some
expressions other than function calls, such as some kind of
conditional.

There may be some tools that could help, such as a parser for Dylan,
or a parser generator.  But I don't know what's available.

However, it may well be that (as per earlier advice) an
evaluator isn't really the best solution.

-- jeff



Sun, 18 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.

Quote:


...
> > Oops, I guess that rules out Dylan!  :-)
....

> For clarification, however, replace "derivatives" with "look-alikes" (i.e.
> Lisp, Scheme, etc.).

   Ah, so it is the parenthesis and not the semantics. :-)

   "In the beginning", Dylan had a prefix syntax.

http://www.basistech.com/tree/dylan/prefix-dylan/book.annotated/annot...

   A few things changed, but it is almost exactly the same language. For the
most
   part, the changes are syntactic suguar to make "Algol derivative"
programmers
   more comfortable.

------

Lyman



Sun, 18 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.


Quote:
>> For clarification, however, replace "derivatives" with "look-
>> alikes" (i.e. Lisp, Scheme, etc.).
> Ah, so it is the parenthesis and not the semantics. :-)

Dead on.  This sounds very silly, I know, but try as I did I could never get
comfortable when coding Lisp or its look-alikes.  I could never read
Lisp-like code.  I could never format it such that I could read it.  This
made it a "write-only" programming language for me -- something which always
makes me nervous (and is why I script in Python rather than Perl, for
example).

ML and Haskell, for example (from my limited exposure to them at any rate),
I find much easier to work with.  Lisp and Scheme and their ilk just don't
do anything for me.

(I also don't like RPN systems for the most part, but I can work with them.
The collections of fingernail clippings that form your average Lisp code,
however, I can't deal with.)

Quote:
> "In the beginning", Dylan had a prefix syntax.

http://www.basistech.com/tree/dylan/prefix-dylan/book.annotated/annot...
nual.html

Quote:
> A few things changed, but it is almost exactly the same language. For the
> most part, the changes are syntactic suguar to make "Algol derivative"
> programmers more comfortable.

I know that "syntactic sugar" is often used derisively, but the fact is that
sugar tastes good.  I *like* syntactic sugar when it is well thought out.
An embeddable language I work with quite a bit (Lua) has a few core features
related to its central mechanism -- essentially associative arrays -- and
then a whole host of syntactic sugar around this to permit a more
"object-oriented" look-and-feel or a more functional look-and-feel or
what-not.  This "sugar" is tasty to this particular developer and, in the
end, makes him more productive.  It may not be ritually pure, but it sure
does work well.

I'm glad that Dylan's creators "sullied" the language by making it
accessible, personally.  :-)

--

          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8



Sun, 18 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.
....

Quote:
> Dead on.  This sounds very silly, I know, but try as I did I could never get
> comfortable when coding Lisp or its look-alikes.  I could never read
> Lisp-like code.

   Probably because you are focusing on the parens and not the semantics.
   The parens should guide the grouping, not be of primary focus.  This is
   somewhat the antithesis of Algol like language where the parenthesis are
   there to get some sort of associative grouping that isn't normally the
   case. Therefore you need to pay close attention.

   It takes practice.  

Quote:
>   I could never format it such that I could read it.

   Indentation is more import than parens.  If you keep that in mind reading
   the standard formatting that Emacs lisp mode conjoles you into
   (which is somewhat canonical anyway) then eventually you won't
    focus so much on the parens.
   [ I suspect you're not using emacs to format your code. You were doing
     it by hand, right? ]

Quote:
> I know that "syntactic sugar" is often used derisively, but the fact is that
> sugar tastes good.

  It takes good, but is it good for you?   "Fruit Loops" , "Lucky Charms",
and
  "Frosted Flakes" are great for getting kids to eat something for breakfast.
  However, they are not particularly good nutrition.

Quote:
> I *like* syntactic sugar when it is well thought out.

  I don't have problem with making syntax adjustments to make expressing
  a problem easier or an abbreviation of a common idiom.
  There is a difference between drawing a language closer to a problem domain
  and familiarity for the programmer's sake.  

  The former has an impact on the long term maintainability of the program.
  The latter resembles "frosted flakes";

  I realize "marketing" is a factor in selling a language.  IMHO it should be
  the most emphasized/critical factor.

Quote:
> An embeddable language I work with quite a bit (Lua) has a few core features

  I guess we'll have to differ here.  Reusing the SAME syntax to mean
different
  things in different contexts doesn't "taste good" to me.  It is one of
those
  clever mechanisms that don't really scale well in large multiple person
projects
  [ at least from my experience. ]

Quote:
> I'm glad that Dylan's creators "sullied" the language by making it
> accessible, personally.  :-)

   Most of the time I don't think of it as "sullied".  However, occasionally
when I
   cannot write a macro as straightfowardly as I would like, I sometimes
   mumble something about how this would be insanely easier if they had kept
   the s-expression syntax.   [   That "simple" Dylan interpreter
   mention elsewhere in the thread.... I'm pretty sure that is
   without macros. ]   And something about the irrationality against
   Lisp and its appearance.

   It is a tradeoff. Probably for the better from the "big picture"
perspective.



Sun, 18 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.

Quote:
> > I'm glad that Dylan's creators "sullied" the language by making it
> > accessible, personally.  :-)

>    Most of the time I don't think of it as "sullied".  However,
>    occasionally when I cannot write a macro as straightfowardly as
>    I would like, I sometimes mumble something about how this would
>    be insanely easier if they had kept the s-expression syntax.
>    [   That "simple" Dylan interpreter mention elsewhere in the
>    thread.... I'm pretty sure that is without macros. ]  ...

That sounds like you may be thinking of my message about a "simple
evaluator in Dylan".  (At least I haven't noticed anything
else that it might be.)

It's certainly true that writing an interpreter for anything
approaching all of Dylan would be difficult; but what I had
in mind was something much simpler, and for many purposes
that would suffice.

(Of course, one could write a Scheme-minus-full-call/cc -- or
other small Lisp -- interpreter in Dylan pretty easily.  Since
people have found that sort of thing useful in Java, it might
be useful in Dylan too.)

BTW, a curious (and non-orthogonal) about Dylan and Scheme is
that they have a moderately sophisticated pattern language
that's used for writing macros but is not available for anything
else.  When programmers become adept at writing macros in Dylan
or Scheme, they can write substantial programs in the pattern
language.  I can't think of another language that has that
powerful a "different paradigm" language embedded in it.
So I wonder whether there's any desire among Dylan and
Scheme programmers to have such pattern-matching more
generally available.

(I realise that the "hygenic" aspects of the pattern language
may be macro-specific, but a similar pattern syntax could
nonetheless be provided in the main language.)

-- jeff



Mon, 19 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.


Quote:
>> Dead on.  This sounds very silly, I know, but try as I did I could never
get
>> comfortable when coding Lisp or its look-alikes.  I could never read
>> Lisp-like code.
> Probably because you are focusing on the parens and not the semantics.
> The parens should guide the grouping, not be of primary focus.  This is
> somewhat the antithesis of Algol like language where the parenthesis are
> there to get some sort of associative grouping that isn't normally the
> case. Therefore you need to pay close attention.
> It takes practice.

I found that the parens interfered with the semantics.  I wasn't willing to
expend the time and effort necessary to practice getting past an ugly
syntax.

Quote:
>> I could never format it such that I could read it.
> [ I suspect you're not using emacs to format your code. You were doing
> it by hand, right? ]

I don't use emacs at all.  I'm not fond of it as an editor: too bloated and
slow for my tastes.

Quote:
>> I know that "syntactic sugar" is often used derisively, but the fact is
that
>> sugar tastes good.
> It takes good, but is it good for you?   "Fruit Loops" , "Lucky Charms",
> and "Frosted Flakes" are great for getting kids to eat something for
breakfast.
> However, they are not particularly good nutrition.

I'll counter with fresh fruit.  It is sweet and tastes good.  It is also
much healthier than the above cited cereals.

Quote:
>> I *like* syntactic sugar when it is well thought out.
> I don't have problem with making syntax adjustments to make expressing
> a problem easier or an abbreviation of a common idiom.
> There is a difference between drawing a language closer to a problem
domain
> and familiarity for the programmer's sake.

Well, algebraic notation alone makes mathematical calculations easier to
express than most alternatives.  "2 + 2" is easier to read for most people
(not even just most programmers) than something like "add(2, 2)" or "2 2
add".  "(2 + 2) * 3 - 2" is similarly easier to read for most people than
"sub(mul(add(2, 2), 3), 2)" or "2 2 add 3 mul 2 sub".

I don't think that making a language comfortable for the vast majority of
programmers to use is a sin myself.  A language is a tool.  Like any tool if
it is designed in such a way that the majority of its potential user base
feel uncomfortable using it, it is of no use.

Quote:
>> An embeddable language I work with quite a bit (Lua) has a few core

features

Quote:
> I guess we'll have to differ here.  Reusing the SAME syntax to mean
> different things in different contexts doesn't "taste good" to me.

Who said anything about using the same syntax to mean different things?  I'm
talking about different syntactic structures boiling down to the same thing
in the implementation.

In Lua one of the central mechanisms is the associative array.  In the end,
the following pieces of code mean exactly the same thing for variable
access:

    array["member"] = 5;
    array.member = 5;

When define functions associated with an array instance (essentially adding
methods to an object), the following are equivalent:

    array["method"] = function(self) end
    array.method = function(self) end
    function array:method() end

When calling said function, these are about the same (but not quite):

    array["method"](array)
    array.method(array)
    array:method()

Why only "almost equivalent"?  Well, the last notation (the one with ':') is
a little different in that "array" is guaranteed to be evaluated only once.
The other ones will evaluate it twice which can have a performance impact
or, in some unusual circumstances involving "tags" may evaluate to two
different objects.

Things actually go a bit deeper than this.  Drop by
http://www.*-*-*.com/ ~lhf/lua/manual/ for the{*filter*}details.

--

          PGP Key: http://www.*-*-*.com/ ~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8



Mon, 19 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.
..

Quote:
> That sounds like you may be thinking of my message about a "simple
> evaluator in Dylan".

   Yes.

Quote:
> It's certainly true that writing an interpreter for anything
> approaching all of Dylan would be difficult; but what I had
> in mind was something much simpler, and for many purposes
> that would suffice.

   I thought as much.  The point I was trying to get across
   was that that task could be simplier if the language consisted of
   simplier constructs.  A tradeoff was made.   I think the Lispers
   tend to realize that and many non-Lispers are totally oblivious
   to the fact there was even a tradeoff to be made.

Quote:
> language.  I can't think of another language that has that
> powerful a "different paradigm" language embedded in it.

   I can, but it isn't generally available. The "Refine" language of
   Reasoning's Software Refinery has multiple paradigm aspect that are
   only available in certain contexts.  Of course "Refine" just gets
translated
   into Lisp anyway. So you could think of it as an extremely complicated
   Lisp macro. ;-)

---

Lyman



Mon, 19 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.
....

Quote:
> > It takes practice.

> I found that the parens interfered with the semantics.  I wasn't willing to
> expend the time and effort necessary to practice getting past an ugly
> syntax.

  The following URL probably is a better response than one I could come up
with.

       http://www.norvig.com/21-days.html

Quote:
> > [ I suspect you're not using emacs to format your code. You were doing
> > it by hand, right? ]

> I don't use emacs at all.  I'm not fond of it as an editor: too bloated and
> slow for my tastes.

  I believe in the right tool for the right job.  I'd refer to some other
editor
  if any of them had a "clue" about lisp. Or for most, the ability to give it
a clue.
  For formatting lisp (and other languages) as I write Emacs does a better
job for
  me than most.  

Quote:
> Well, algebraic notation alone makes mathematical calculations easier to
> express than most alternatives.

  How many heavily OO programs consist largely of mathematical calculations?

Quote:
> it is designed in such a way that the majority of its potential user base
> feel uncomfortable using it, it is of no use.

  If that discomfort were permanent I would agree.  It isn't.
  First impressions usually have a dispportionate impact on people. If
  you let yourself be ruled by them I think you will miss a great many things
  along the way.

  So people who natively speak a Romance languages should only ever learn
  other Romance languages because they'll be more "comfortable" than learning
  something with significantly different structure.   If they were all being
  made to learn by some external mandate, then I'd say that might be the
  best choice in a difficult situations.  However, as a general rule of thumb
  I don't find it very satisfactory.

Quote:
> > I guess we'll have to differ here.  Reusing the SAME syntax to mean
> > different things in different contexts doesn't "taste good" to me.

> Who said anything about using the same syntax to mean different things?  

   LUA does.

      foo[bar]

   can be extended to mean just about anything.  So can syntactic
   equivalent foo.bar .  It depends on what foo really is and what
   fallback you have installed.  That is what I mean by "context"

   Lisp has one construct, but you get more flexibility internal to the
construct.
   You have a left paren, a name, some stuff, and a right paren.  

       (baz  foo  bar  )  or  (baz  bar foo )

   Depending upon what the name is determines what the structure of the
"stuff".
   Since this "stuff"  may be some arbritrary AST, having the AST reprensent
by a
   list turns out to be convenient.  I'm not limited to "." or "[]" as my
   only syntactical markers.  In other words overloading those particular
symbols
   ad infinitum isn't neccesarry.  I could pick two groups, but I don't have
to.

   This also makes it easier to write code that itself writes code.  You
can't
   write code that writes code in LUA. It isn't impossible.  However, it is
   much more difficult to add which is one reason it isn't provided.

   I don't think all programming languages should use s-expressions prefix
syntax.
   I don't think all have to avoid it either. Nor it is extremely difficult
to get
   used to. You have to be motivated to learn it though.

   In short, there is a difference between "Lisp is difficult to learn" and
"I
   don't want to learn Lisp".  The latter is fine, but it doesn't make the
former
   true.

---

Lyman



Mon, 19 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.


Quote:
>>> It takes practice.
>> I found that the parens interfered with the semantics.  I wasn't willing
to
>> expend the time and effort necessary to practice getting past an ugly
>> syntax.
> The following URL probably is a better response than one I could come up
> with.
> http://www.norvig.com/21-days.html

Invalid parallel.  I'm not asking to learn programming from scratch in a few
months.  I already knew software development quite well at the time.  I was
asking to learn a new language.

Moving from very good knowledge of C++ to reasonably competent Dylan
knowledge was something which took me about two months of effort.  What do I
mean by "reasonably competent" here?  Well, I'm at the stage now where I
could do anything I was able to do in C++ in Dylan with only a slight
increase in the time required.  The resulting Dylan code won't be the best
Dylan code in the world, but it will work.

Attempting the same thing with Scheme last year sometime (at about this
time, in fact) had me dropping it as still an effective Scheme novice after
approximately the same period of time.  What do I mean by "effective novice"
here?  I still hadn't got past writing simple examples-oriented programs
yet.

What was the major barrier with Scheme?  I still hadn't even begun to read
Scheme code -- even the stuff I had written myself -- fluently in that time.
I found myself able to read my own Dylan code fluently in a few days and
other peoples' Dylan code (within the subset of Dylan features I had learned
up to that point) in a few weeks.

Given that Dylan and Scheme share many features at the conceptual level, it
strikes me that the problems I had learning Scheme weren't because I was
rushing the comprehension of concepts but rather because the language's look
and feel didn't match what was convenient and easy for me to learn.  And
since time is, in fact, not an infinite commodity in my life, I appreciate
it when others spend the time to make a tool such that my time expended is
reduced.

Quote:
>> I don't use emacs at all.  I'm not fond of it as an editor:
>> too bloated and slow for my tastes.
> I believe in the right tool for the right job.

As do I.  I don't think that a slow and bloated text editor is the right
tool for the job of editing text files.

Quote:
>> Well, algebraic notation alone makes mathematical calculations
>> easier to express than most alternatives.
> How many heavily OO programs consist largely of mathematical calculations?

How many heavily OO programs consist largely of closures?  Doesn't the
convenient syntax for closures (as opposed to the klunky "functor" nonsense
of C++) nonetheless serve a useful purpose?

Quote:
> If that discomfort were permanent I would agree.  It isn't.

Two or so months of trying Scheme left me with the same amount of
discomfort.  And Scheme was the third (fourth?) Lisp-like language I had
tried in the past decade or so.

Here's a radical notion: maybe different people react differently to the
same stimulus!  Maybe the UNIX way of doing something, for example, causes
projectile vomiting in Mac programmers.  Maybe Lisp-style syntax is just a
poor fit for some developers?

Nah.  It couldn't be that simple.  There is obviously always One True Way.

Quote:
> First impressions usually have a dispportionate impact on
> people. If you let yourself be ruled by them I think you will
> miss a great many things along the way.

And if you don't let your first impressions have an impact on you (not that
I didn't try to work around them in the case of Scheme and Lisp, mind), you
wind up wasting so much time on things that don't work for you that you miss
a great many things along the way as well.  Time is a finite resource,
remember.

Quote:
> So people who natively speak a Romance languages should only
> ever learn other Romance languages because they'll be more
> "comfortable" than learning something with significantly different
> structure.

If they don't derive enjoyment from learning a non-Romance language and have
no compelling reason (social, professional or otherwise) to do so, of course
they shouldn't bother learning a non-Romance language.  Or do you think they
should be compelled to because you happen to like non-Romance languages?

Quote:
>> Who said anything about using the same syntax to mean different things?
> LUA does.
> foo[bar]
> can be extended to mean just about anything.  So can syntactic
> equivalent foo.bar .  It depends on what foo really is and what
> fallback you have installed.  That is what I mean by "context"

That wasn't the syntactic sugar I was talking about.  (As the example you
snipped clearly demonstrated, incidentally.)

Quote:
> I don't think all programming languages should use s-expressions
> prefix syntax.

Good.

Quote:
> I don't think all have to avoid it either.

True.  But if they want widespread use they probably should avoid it.  The
Scheme Underground notwithstanding, Lisp-like (in terms of "look and feel")
languages aren't going to be replacing Algol-like languages anytime soon.

Quote:
> Nor it is extremely difficult to get used to.

My experience dictates otherwise.

Quote:
> You have to be motivated to learn it though.

And what could possibly motivate me to slog through a syntax I abhor when I
can go to any number of other languages which I don't hate?  About the only
motivation I could see at this stage would be having my (hypothetical) son
held hostage and having one of the terms of release be "you will code this
program in Lisp or your son dies".  And even there I'd have to REALLY love
my son....

Quote:
> In short, there is a difference between "Lisp is difficult to
> learn" and "I don't want to learn Lisp".

Agreed.  But the fact that many (most?) people find Lisp more difficult to
learn than other languages pretty much makes it obvious which of the two is
true.

--

          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8



Mon, 19 Nov 2001 03:00:00 GMT  
 Another undoubtedly stupid question.

Quote:
> I found that the parens interfered with the semantics.  I wasn't willing to
> expend the time and effort necessary to practice getting past an ugly
> syntax.

How much time & effort were you not willing to expend?  I can't
believe the time required to become fluent in Lisp (or almost any
other) syntax is not just negligible compared with the time required
to actually become competent in a language, which is probably years
for most people.  Rejecting a language because of syntax (unless that
syntax is cripplingly bad in some low-level way which means humans
just can't understand it) seems to me a classic case of short-term
considerations dominating the actual correct costing of something (and
thus a very human thing to do I guess).

--tim



Tue, 20 Nov 2001 03:00:00 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. No eval in Dylan (was RE: Another undoubtedly stupid question.)

2. Serious, but undoubtedly trivial, question

3. Bibliographic format processor (was Re: Serious, but undoubtedly

4. Seemingly Stupid Question

5. Stupid question

6. Stupid Question 101

7. Really stupid question

8. Stupid newb question: What am I doing wrong?

9. Stupid question...Is sed in gawk??

10. Really stupid question...

11. Stupid Canvas question

12. Stupid swiki questions.

 

 
Powered by phpBB® Forum Software