 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/04/2010 10:32 PM, Jim Henderson wrote:
> On Thu, 22 Apr 2010 21:28:57 +0100, Stephen wrote:
>
>> On 22/04/2010 9:02 PM, Jim Henderson wrote:
>>
>>> Apparently not. Dunno the current state, as I don't use Windows...
>>>
>>> Jim
>>
>> Your lighting bill must be huge ;-)
>
> :P
>
> Not so much, though, I prefer the darkness generally. ;-)
>
Have you checked your reflection in a mirror, lately?
--
Best Regards,
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Is there some advantage to supporting regular expressions?
>
> Yes, because if you don't know the exact string you're looking for, you
> can specify a more general string that is likely to be found.
Surely this almost never actually works though?
> I use it several times a week myself, reasons include chat log files in
> my IM client where I might need to find a conversation I've had in the
> past about something. I recently was trying to remember the name of an
> internal website, but I couldn't remember who I had talked to about it or
> the website name. I was able to use grep to find what I needed in a
> matter of seconds without searching (checks - "find -type f | wc -l" -
> 8694 chat log files across all the different IM protocols I use).
>
> Doing that by hand would be very tedious and would take days, and even
> then, I might not find what I was looking for.
As I say, not the kind of thing I ever need to do. (Although
occasionally I wish it was possible to search this newsgroup...)
>>> As Warp said, you also can traverse a directory structure with grep to
>>> find the file(s) that have the string in them.
>> I didn't know that. I thought grep was just for searching within one
>> file.
>
> If I tell you the 'net is wonderful resource for information, what will
> you say in response? ;-)
Suffice it to say that since I don't need grep, I hadn't deeply
researched its capabilities. (I only recently discovered that it's a
search tool, for example.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah, well, I had noticed that you seem to know far more about COM
>> than I do.
>
> Not *that* much. Maybe a half a day's worth of learning?
Heh. I've spent somewhat more than half a day reading about it. What
I'll probably never do is actually use it...
>>> Which implementation do you use?
>> Smalltalk VisualWorks. I *think* it was v3.0...
>
> http://www.cincomsmalltalk.com/documentation/current/ReleaseNotes7.5.pdf
>
> They were up to a version that supports it (7.5) five years ago. You
> were working with V3.0. Perhaps you were using a pre-COM version that
> wouldn't run under Win98 or something?
No, we were running it under Windows 98. I guess the release we had just
didn't have COM support implemented yet. (Remember that Smalltalk is
basically its own little world. Talking to stuff outside probably isn't
a high priority.)
I recall having a look at v5 (I think) at some point, and while they'd
added lots of nice features, they made the system too complicated. I
didn't like it, so I went back to v3.
>>> Plus, you probably use Word and Excel, and they both support COM too.
>> You mean VBA supports COM?
>
> How do you think VBA talks to the application? Of course it supports
> COM. That's pretty much *all* it supports. It doesn't really do anything
> on its own.
Well, I guess that makes sense.
On the other hand, VBA doesn't seem to require you to memorise 20-digit
GUIDs or interface index numbers or any of the other stuff that the COM
documentation seems to indicate is necessary, so...?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan <m.n### [at] ieee org> wrote:
> So why compare with Linux? You're comparing with OpenSUSE.
OpenSUSE is the only distro deserving of a mention... ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/23/10 04:00, Warp wrote:
> Neeum Zawan <m.n### [at] ieeeorg> wrote:
>> So why compare with Linux? You're comparing with OpenSUSE.
>
> OpenSUSE is the only distro deserving of a mention... ;)
This means WAR!
--
Every hard drive I've ever bought has been larger than all my previous
hard drives combined. And this is without even trying.
--Seen on Slashdot.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> OpenSUSE is the only distro deserving of a mention... ;)
>
> This means WAR!
First there was Emacs vs Vi.
Then there was Windows vs Linux.
Then came AMD vs Intel.
And now we must have the War of the Distros. My god... it'll be terrifying!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> On the other hand, VBA doesn't seem to require you to memorise 20-digit
> GUIDs or interface index numbers or any of the other stuff that the COM
> documentation seems to indicate is necessary, so...?
I'm not sure what the question is. What do you think CreateObject does?
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> OpenSUSE is the only distro deserving of a mention... ;)
>
It's not often that I agree with you, but you're right :-)
John
--
Cogito sum,|| wbu### [at] tznvypbz (rot'ed) || GPG Key Fingerprint:
ergo sum, || These opinions are mine alone, || 0D9BCF4CF1B71CA2F5F7
cogito || others can find their own || BFBBCBC34EDEAEFCE453
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> On the other hand, VBA doesn't seem to require you to memorise
>> 20-digit GUIDs or interface index numbers or any of the other stuff
>> that the COM documentation seems to indicate is necessary, so...?
>
> I'm not sure what the question is. What do you think CreateObject does?
What's CreateObject?
All I know is that I've never seen any VBA code with 20-digit GUIDs in
it. And I've never seen it in documentation either. It just pretends
that you're manipulating objects.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 23 Apr 2010 06:26:24 +0100, Stephen wrote:
>> Not so much, though, I prefer the darkness generally. ;-)
>>
>>
> Have you checked your reflection in a mirror, lately?
It's too dark for mirrors. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 23 Apr 2010 09:04:37 +0100, Invisible wrote:
>>> Is there some advantage to supporting regular expressions?
>>
>> Yes, because if you don't know the exact string you're looking for, you
>> can specify a more general string that is likely to be found.
>
> Surely this almost never actually works though?
Obviously I'd prefer to spend my time doing something that "almost never
actually works", right? (IOW, the fact that I do in fact do this should
demonstrate to you that it *does* actually work more often than not,
because I'm not likely to waste my time doing something that is unlikely
to work).
>> Doing that by hand would be very tedious and would take days, and even
>> then, I might not find what I was looking for.
>
> As I say, not the kind of thing I ever need to do. (Although
> occasionally I wish it was possible to search this newsgroup...)
That's actually something I do use it for as well - I've been known to
scrape newsgroups with a perl script, dump the contents, and then use
grep to parse the output file to find a message I was looking for based
on something in the message text.
>>>> As Warp said, you also can traverse a directory structure with grep
>>>> to find the file(s) that have the string in them.
>>> I didn't know that. I thought grep was just for searching within one
>>> file.
>>
>> If I tell you the 'net is wonderful resource for information, what will
>> you say in response? ;-)
>
> Suffice it to say that since I don't need grep, I hadn't deeply
> researched its capabilities. (I only recently discovered that it's a
> search tool, for example.)
Well, perhaps you would benefit from using it (perhaps not), but just
because you weren't aware of its capabilities, you never considered it as
an option to accomplish a task. It's only natural that one wouldn't use
a tool that might be well suited for a task if one doesn't know about the
tool or fully understand its capabilities.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 23 Apr 2010 07:00:25 -0400, Warp wrote:
> Neeum Zawan <m.n### [at] ieeeorg> wrote:
>> So why compare with Linux? You're comparing with OpenSUSE.
>
> OpenSUSE is the only distro deserving of a mention... ;)
FTW! :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Darren New wrote:
>> Invisible wrote:
>>> On the other hand, VBA doesn't seem to require you to memorise
>>> 20-digit GUIDs or interface index numbers or any of the other stuff
>>> that the COM documentation seems to indicate is necessary, so...?
>>
>> I'm not sure what the question is. What do you think CreateObject does?
>
> What's CreateObject?
It looks up names in the registry and translates them to 20-digit GUIDs.
It's like complaining you don't see IP addresses in hyperlinks, so the web
must not use IP.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> No, I mean... I thought grep can only search within a single file (as
> can any decent text editor). I didn't realise it can search multiple
> files.
>
> (I'm still having trouble thinking up a use-case for that. About the
> only thing I can think of is trying to find out which header file
> defines a particular symbol or something.)
Yesterday, the 'parted' tool was giving me a totally cryptic error message.
$ apt-get source parted
$ cd parted-2.2
$ grep -rn "error message here" .
-r makes search recursive, -n makes grep output line numbers next to the
filenames. Then I opened a text editor on the file and line number that grep
mentioned, and tried to figure out the code :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Um... why? Three lines of text doesn't take "minutes" to write. And
>> that's about all it takes to search a folder for a file matching a
>> condition. (Obviously, it depends on how complicated the condition is...)
>
> How long does it take you to write a program which does the same thing
> as this:
>
> fgrep '#include "header.hh"' *.cc
>
There could be more spaces.
grep '#include[[:space:]]\+"header.hh"' *.cc
How long would it take to write a program that can match that, taking into
account that there could be multiple spaces?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Warp wrote:
>> So what? I'm not interested in how much disk space the file is taking.
>
> But most other people are. Hence the default UI.
Default UI? There is no option to make it work in a different way. It's not
the default UI, it's the *only* UI.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> Warp wrote:
>> Invisible <voi### [at] devnull> wrote:
>>> Mostly because even on a PC with hardware far in advance of what the
>>> Amiga has, Windows was *vastly* slower.
>>
>> Far in advance? 12MHz CPU (if you were rich), no hardware graphics
>> acceleration of any kind, 16 colors (again, if you were rich)... How is
>> that "far in advance of what the Amiga has"?
>
> Because the PCs at college had 133 MHz CPUs and 32 MB of RAM - multiple
> times the Amiga's 7 MHz CPU (admittedly of completely different design)
> and 2 MB of RAM. And yet, on such a machine, even something as simple as
> closing a window causes huge amounts of disk thrashing.
Something "as simple" is not as simple as it seems. Like, something as
simple as displaying lines of text on the screen could take a few
seconds on early mainframes and PCs...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Thu, 22 Apr 2010 09:10:03 +0100, Invisible wrote:
>
>> (I'm still having trouble thinking up a use-case for that. About the
>> only thing I can think of is trying to find out which header file
>> defines a particular symbol or something.)
>
> Header file definitions, sure.
>
> Some of the things I grep for regularly:
>
> Which file contains contract information for a particular partner?
>
> Which of the chat log files I have contains a reference to a particular
> website, user ID, password, or discussion?
Which of the lines in this chat log contains a normal message, as opposed to
information like "Jim has joined #povray" or "Logfile started"?
I piped the result of that grep into 'sed' to extract only the username,
then sort | uniq -c | sort -n, and I got an ordered list of who talks the
most in the chatroom :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> 3. It really takes that much code just to do the same task as DIR /B C:\
> C:\FileList.txt?
Says the guy who would rather write his own program to do specific searches
than figure out grep :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> scott wrote:
>> Obviously it's just a simple example so you can see how it works.
>
> Wikipedia seems to indicate that WSH supports JavaScript. I wonder if I
> can get that to work...
var fso = new ActiveXObject("Scripting.FileSystemObject");
var sFolder = "C:\\tmp";
var newFile = fso.CreateTextFile(sFolder+"\\FileList.txt", true);
var folder = fso.GetFolder(sFolder);
var files = folder.Files;
// yes, enumerating COM collections really is this messy in Javascript
var filesEnum = new Enumerator(files);
for (; !filesEnum.atEnd(); filesEnum.moveNext()) {
var file = filesEnum.item();
newFile.WriteLine(file.Name);
}
newFile.Close();
WScript.Echo("Done!");
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 23 Apr 2010 18:03:30 -0300, Nicolas Alvarez wrote:
> Which of the lines in this chat log contains a normal message, as
> opposed to information like "Jim has joined #povray" or "Logfile
> started"?
>
> I piped the result of that grep into 'sed' to extract only the username,
> then sort | uniq -c | sort -n, and I got an ordered list of who talks
> the most in the chatroom :)
Yep, that would work too. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New wrote:
>> Warp wrote:
>>> So what? I'm not interested in how much disk space the file is taking.
>> But most other people are. Hence the default UI.
>
> Default UI? There is no option to make it work in a different way.
There's no option included in the software as it comes from the manufacturer
to make it work differently, no.
> It's not
> the default UI, it's the *only* UI.
"Default" means "unless you do something." :-)
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> > fgrep '#include "header.hh"' *.cc
> There could be more spaces.
> grep '#include[[:space:]]\+"header.hh"' *.cc
Well, since it's not possible to have two #-commands in the same line,
and having anything else between the #include and the file name is unlikely,
you could just as well do it line:
grep '#include.*"header.hh"' *.cc
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2010 6:47 PM, Jim Henderson wrote:
> On Fri, 23 Apr 2010 06:26:24 +0100, Stephen wrote:
>
>>> Not so much, though, I prefer the darkness generally. ;-)
>>>
>>>
>> Have you checked your reflection in a mirror, lately?
>
> It's too dark for mirrors. ;-)
>
> Jim
LOL
--
Best Regards,
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Yesterday, the 'parted' tool was giving me a totally cryptic error message.
>
> $ apt-get source parted
> $ cd parted-2.2
> $ grep -rn "error message here" .
>
> -r makes search recursive, -n makes grep output line numbers next to the
> filenames. Then I opened a text editor on the file and line number that grep
> mentioned, and tried to figure out the code :)
Isn't trying to figure out why an arbitrary piece of code doesn't work
formally equivilent to the Halting Problem? (With non-termination simply
being the most basic kind of program bug...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> What's CreateObject?
>
> It looks up names in the registry and translates them to 20-digit GUIDs.
See, you definitely know far more about COM than I do. I wasn't even
aware that there *are* names associated with GUIDs...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Invisible wrote:
>> 3. It really takes that much code just to do the same task as DIR /B C:\
>> C:\FileList.txt?
>
> Says the guy who would rather write his own program to do specific searches
> than figure out grep :)
Or rather, I'd rather write my own program than use grep for a *complex*
search. (E.g., find anything that's a valid XML fragment.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Or rather, I'd rather write my own program than use grep for a *complex*
> search. (E.g., find anything that's a valid XML fragment.)
Don't start making unfair comparisons. 'grep' (as well as other similar
tools such as 'sed') is a line-based tool. It can match individual *lines*
of the input. It cannot be used to perform operations which would require
interpreting several lines (unless it has some non-standard extensions).
Recognizing a valid XML fragment would require interpreting several lines
of the input (if you want to be able to match all possible cases), and hence
'grep' cannot be used for that.
'grep' is most useful for finding things you know are all in one line,
and for filtering files with a known format (such as httpd logs).
If you need more complicated things like that, then often 'awk' or 'perl'
can be used (still usually with shorter commands and faster than writing
your own program would). For example 'perl' can be used for the same things
as 'grep' and 'sed', but it has a vastly expanded set of match patterns and
other instructions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Or rather, I'd rather write my own program than use grep for a *complex*
>> search. (E.g., find anything that's a valid XML fragment.)
>
> Don't start making unfair comparisons. 'grep' (as well as other similar
> tools such as 'sed') is a line-based tool. It can match individual *lines*
> of the input. It cannot be used to perform operations which would require
> interpreting several lines (unless it has some non-standard extensions).
>
> Recognizing a valid XML fragment would require interpreting several lines
> of the input (if you want to be able to match all possible cases), and hence
> 'grep' cannot be used for that.
Right. And when I do text processing, this is the kind of task I usually
want to do. Which is perhaps why grep doesn't sound especially useful to me.
Still, if your goal is just to find out if (or where) a file contains a
particular word or code number, I agree that grep is probably the
fastest way to find it.
> 'grep' is most useful for finding things you know are all in one line,
> and for filtering files with a known format (such as httpd logs).
I gather line-based file formats are quite common in Unix. (E.g., fstab
is line-based, IIRC.) Such things are comparatively rare for Windows
though. About the closest thing is CSV files. But - as I recently
discovered - CSV isn't really line-based. (A single record can span
multiple lines. At least, according to the RFC.)
> If you need more complicated things like that, then often 'awk' or 'perl'
> can be used (still usually with shorter commands and faster than writing
> your own program would).
I would debate that, but let's not start another argument...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> > If you need more complicated things like that, then often 'awk' or 'perl'
> > can be used (still usually with shorter commands and faster than writing
> > your own program would).
> I would debate that, but let's not start another argument...
Are you saying that you don't think one could write a significantly
shorter command using perl than with your favorite language? Maybe you
just don't know that perl can be used directly from the command line,
giving the "program" as an argument, and hence it can be used very much
like grep or sed. For example:
perl -pe 's|\d+|$&+1|ge' file.txt
This searches for any consecutive digits in 'file.txt', interprets them
as numbers and outputs the contents of the file but with each of these
numbers incremented by 1. (Thus if the file had a something like
"value = 123;" somewhere, the result would have "value = 124;" instead.)
I don't know Haskell too well, but I'm pretty certain it takes a bit
more code to do that (and additionally you probably can't just write the
code on the command line).
(And yes, I know that the string given to perl looks gibberish to you.
It's not gibberish when you understand what it means.)
Of course this is just a simple example. Perl can be used to make
significantly more complex substitutions (and other things) in a similar
way.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I would debate that, but let's not start another argument...
>
> Are you saying that you don't think one could write a significantly
> shorter command using perl than with your favorite language?
...alternatively, let's start another argument... *sigh*
>
> perl -pe 's|\d+|$&+1|ge' file.txt
>
> This searches for any consecutive digits in 'file.txt', interprets them
> as numbers and outputs the contents of the file but with each of these
> numbers incremented by 1. (Thus if the file had a something like
> "value = 123;" somewhere, the result would have "value = 124;" instead.)
>
> I don't know Haskell too well, but I'm pretty certain it takes a bit
> more code to do that
It does. (If only because of the difficulty of number parsing.) But a
more relevant question would be... why would you want to do this? Is
Haskell (or anything else) easier or harder for textual manipulations
that actually do something useful?
> (and additionally you probably can't just write the
> code on the command line).
Actually you can. (But obviously you *only* want to do this if the code
is short...)
> Of course this is just a simple example. Perl can be used to make
> significantly more complex substitutions (and other things) in a similar
> way.
Again, I guess it depends on what you want to do. For example, some guy
invented "markdown", and wrote a Perl script to turn it into HTML or
whatever. And then a bunch of Haskell guys wrote their own
implementation, which was faster, had fewer bugs (i.e., it matched the
documentation more closely), and had more features.
Then again, not every task is as complicated as markup conversion...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> why would you want to do this?
Why would one want to do pattern substitution?
Obviously nobody wants to do that, which is why there are no tools to do
that from, like, forever, like eg. 'sed' or 'perl'.
I'm sure even you have used search&replace. This is the same, except that
it's significantly more expressive and can be automated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 24 Apr 2010 09:04:40 +0100, Orchid XP v8 wrote:
> Nicolas Alvarez wrote:
>
>> Yesterday, the 'parted' tool was giving me a totally cryptic error
>> message.
>>
>> $ apt-get source parted
>> $ cd parted-2.2
>> $ grep -rn "error message here" .
>>
>> -r makes search recursive, -n makes grep output line numbers next to
>> the filenames. Then I opened a text editor on the file and line number
>> that grep mentioned, and tried to figure out the code :)
>
> Isn't trying to figure out why an arbitrary piece of code doesn't work
> formally equivilent to the Halting Problem? (With non-termination simply
> being the most basic kind of program bug...)
You're not asking grep to tell you why it failed, just to tell you where
in the code the error is so one can manually inspect the file and see if
one can determine why the failure occurred.
Done that many times myself.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Isn't trying to figure out why an arbitrary piece of code doesn't work
> formally equivilent to the Halting Problem?
No.
The code works, in the formal sense. It just doesn't do what you want it to do.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Such things are comparatively rare for Windows though.
INI files is about it. Anything more complicated either goes in the registry
or into an XML file, if it's configuration. Some log files actually go into
text files, but that's mostly things like httpd logs there, too.
>> can be used (still usually with shorter commands and faster than writing
>> your own program would).
>
> I would debate that, but let's not start another argument...
Using Perl *is* writing your own program. And I expect the parser generator
in Haskell isn't a whole lot harder than an equivalet program in Perl.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Why would one want to do pattern substitution?
Personally, I usually wind up wanting to do complex pattern manipulation on
file names, rather than file contents.
Stuff like "go through these directories full of image files, figure out
whether it's months, days, or hours that's changing, rename all the files to
match the time they were taking excluding the parts of the date that's the
same for all the files, tack on a letter saying which camera took the
picture, then another letter to disambiguate multiple photos taken within
the same minute. Also, copy any sequence of three or more photos taken
within 5 seconds of each other with a one-minute gap on either side to a
separate directory to be stitched together as a panorama."
That's gonna be rough to do with command-line tools too. Not impossible, but
certainly something easier in an actual scripting language better than Bash.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v8 wrote:
>> Isn't trying to figure out why an arbitrary piece of code doesn't work
>> formally equivilent to the Halting Problem?
>
> No.
>
> The code works, in the formal sense. It just doesn't do what you want it
> to do.
Or, to clarify...
If by "works" you mean "obeys the formal specification", then yes, you can
prove it. Write a formal spec for what sequence a Haskell program can
output, such as a BNF grammar. Now analyze your Haskell program to see if
the parser you wrote follows the BNF.
Computers do this all the time. There's an input language the compiler
accepts. It can tell whether the input matches the language spec, and if so,
the program "works", in some sense.
And indeed, this is called the field of "program verification", pioneered by
those who invented structured programming and such.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Nicolas Alvarez wrote:
>> Invisible wrote:
>>> 3. It really takes that much code just to do the same task as DIR /B C:\
>>> C:\FileList.txt?
>>
>> Says the guy who would rather write his own program to do specific
>> searches than figure out grep :)
>
> Or rather, I'd rather write my own program than use grep for a *complex*
> search. (E.g., find anything that's a valid XML fragment.)
>
Well, sure. Regular expressions are almost always the wrong tool for XML.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Isn't trying to figure out why an arbitrary piece of code doesn't work
>> formally equivilent to the Halting Problem? (With non-termination simply
>> being the most basic kind of program bug...)
>
> You're not asking grep to tell you why it failed, just to tell you where
> in the code the error is so one can manually inspect the file and see if
> one can determine why the failure occurred.
Oh, sure. I just meant that even once grep has found the location for
you, the task you're attempting to perform is almost impossible anyway...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> why would you want to do this?
>
> Why would one want to do pattern substitution?
No, why would you want to find anything that's a number, parse it, and
add one to it. It doesn't seem like a particularly useful example. I'm
sure the same techniques could be used to do something more useful, but
I can't think of an example.
Anyway, I forget how we even got started on this topic, but this debate
has gone on long enough to make a few things clear. It seems that
low-level text munging is useful for the kind of stuff you do, and not
especially useful for the kind of stuff I do. Let's leave it at that.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Oh, sure. I just meant that even once grep has found the location for
> you, the task you're attempting to perform is almost impossible anyway...
And... you program computers? Why, if you find it almost impossible?
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 24 Apr 2010 19:27:38 +0100, Orchid XP v8 wrote:
>>> Isn't trying to figure out why an arbitrary piece of code doesn't work
>>> formally equivilent to the Halting Problem? (With non-termination
>>> simply being the most basic kind of program bug...)
>>
>> You're not asking grep to tell you why it failed, just to tell you
>> where in the code the error is so one can manually inspect the file and
>> see if one can determine why the failure occurred.
>
> Oh, sure. I just meant that even once grep has found the location for
> you, the task you're attempting to perform is almost impossible
> anyway...
Clearly it is, because I've only done it several times in my lifetime. ;-)
Come to that, I've even somehow managed this "impossible" or "almost
impossible" task a few times *without access to the code*. <gasp>
(There you go again, assuming because you can't see how it could be done
that it must be absolutely impossible for anyone to do - you really need
to stop doing that).
Now, from a *practical* standpoint, with access to the source, the way I
would do it is this:
1. Grep for the error code in the source tree.
2. Look at the function the error code is in; if it's a generic error
function, then it becomes a little more tricky, but not impossibly so,
because:
3. I can use a tool like Source Navigator NG to show me the function
call stack; walking backwards through the stack and seeing what
conditions must exist in order to end up with that error message can
point to several causes.
4. Then look at the options for causes, and see which one is likely on
the system.
5. If it is easy to reproduce the cause, try it and see if the result is
what was expected.
Not so difficult to do - and I don't have a background in software
engineering. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 24 Apr 2010 19:30:52 +0100, Orchid XP v8 wrote:
> Warp wrote:
>> Orchid XP v8 <voi### [at] devnull> wrote:
>>> why would you want to do this?
>>
>> Why would one want to do pattern substitution?
>
> No, why would you want to find anything that's a number, parse it, and
> add one to it. It doesn't seem like a particularly useful example. I'm
> sure the same techniques could be used to do something more useful, but
> I can't think of an example.
Immediately one that comes to me is the output of a program that was off
by one - and the original program is no longer available or it would take
longer to re-run than to just correct the data.
> Anyway, I forget how we even got started on this topic, but this debate
> has gone on long enough to make a few things clear. It seems that
> low-level text munging is useful for the kind of stuff you do, and not
> especially useful for the kind of stuff I do. Let's leave it at that.
It's entirely possible if you understood it better and what the
capabilities of the various programs are, you could save yourself time
(either now or in the future) by not doing things in a way that is harder
or takes more time.
I said earlier that I'm not a software engineer - and I'm not. I took a
few courses in programming and Computer Science when I was at uni, but I
do understand that if the only language you know is BASIC (the first
language I learned - Commodore BASIC), many things will seem impossible
to do because the *tool* is limited. By understanding that there are
other tools available and some tools are better suited to accomplish a
task than others, you broaden your ability to get the job done
efficiently.
If I had stuck with just programming in C (which was may main language of
choice), then doing the types of data manipulation I do with awk or sed
(I prefer the former, actually, but can use both), I'd be stuck in a
cycle of code, compile, run, analyze, modify code, compile, run,
analyze.....which takes a lot more time.
In C, a program to search and traverse the directory structure would be
quite long (actually, one can see what's involved by looking at the
source for grep!), but using a tool that's built for that purpose? Much
more efficient than building your own.
You know the old saying, when the only tool you have is a hammer,
everything looks like a nail?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> You know the old saying, when the only tool you have is a hammer,
> everything looks like a nail?
everything looks like a thumb.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 24 Apr 2010 14:40:57 -0700, Darren New wrote:
> Jim Henderson wrote:
>> You know the old saying, when the only tool you have is a hammer,
>> everything looks like a nail?
>
> everything looks like a thumb.
LOL, too true!
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > Orchid XP v8 <voi### [at] devnull> wrote:
> >> why would you want to do this?
> >
> > Why would one want to do pattern substitution?
> No, why would you want to find anything that's a number, parse it, and
> add one to it.
You don't understand the concept of a simple example, do you?
An example is a simple proof-of-concept which demonstrates a feature.
Asking "why would you want to do that" is idiotic when we are talking
about examples.
If you give someone an example of a short Haskell program which prints
"Hello World!", and that someone would then ask you "why would you want
to do that?", wouldn't you consider him an idiot? He is *missing the point*.
It was just an example to demonstrate something.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v8 wrote:
>> Oh, sure. I just meant that even once grep has found the location for
>> you, the task you're attempting to perform is almost impossible anyway...
>
> And... you program computers? Why, if you find it almost impossible?
My programs aren't arbitrary. They have some kind of structure to them.
Other people's programs do not necessarily have this property.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> My programs aren't arbitrary. They have some kind of structure to them.
> Other people's programs do not necessarily have this property.
So, everyone else is a *worse* programmer than you? And they write random
programs with no purpose? ;-)
Here's the deal that Turing figured out. You can't take every *arbitrary*
program, i.e., one created by generating a bunch of machine code
instructions with a random number generator, and figure out what it's going
to do without running it. But that's not how people write programs.
You also can't check that a program is typesafe, because you can't tell if
an arbitrary program every assigns the wrong type to a variable. But we
design strongly-typed programming languages that disallow well-typed
programs that the compiler can't prove are well-typed.
Since people don't debug arbitrary random programs, it's usually (usually!)
fairly easy to figure out, when you get an error message, what caused it.
Certainly easier than when you get no error message and just the wrong answers.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 25 Apr 2010 09:35:34 +0100, Orchid XP v8 wrote:
> My programs aren't arbitrary. They have some kind of structure to them.
> Other people's programs do not necessarily have this property.
There's a difference between "arbitrary" and "complex".
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It has its drawbacks, too. Having a file named -rf in your home directory
> leads to problems, for example. Before shells properly escaped
> everything, files with spaces in the names were very problematic as well.
Took me a long time to figure out the CAD system on our Unix box was
crashing because the path name had a space in it, not because the file was
corrupt somehow...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
