[OT] Grumble...

[Daniel Pitts]

I use the old Thompson toolkit ( http://tasoft.com/) since it is
written in Win32 assembly for speed ! The Thompson toolkit
includes a c shell and the fastest grep that I have ever seen.

Lynn

But beware of the Thompson hack. ;-)

 

[Lynn McGuire]

I use the old Thompson toolkit ( http://tasoft.com/) since it is

But beware of the Thompson hack. ;-)

Neat idea ! http://en.wikipedia.org/wiki/Thompson_hack

Different Thompson (I think !).

Lynn

 

[jacob navia]

Miles Bader a écrit :

As an example, there are many occasions when VS will display an address
(say, in a memory dump or something), and I want to see what's at that
address, interpreted in a different way. In gdb, I can almost always do
this using an expression that operates on the previous value, or by
using command-line editing to tweak a previous command. In
VS... there's often simply no obvious way to do it -- even the obvious
GUIey cut-and-paste solution doesn't work, because copying simply isn't
supported in many contexts, and after much gnashing of teeth, consulting
with other users, looking in the menus/doc/etc, I often just end up
typing the damn value in by hand. This sort of "information displayed,
but not otherwise usable" situation crops up _all the time_ when I use
VS for debugging (and it's not like I don't try to find a way to do it
-- I ask regular users, spend time searching the menus, look at the
docs, etc, but usually to no avail).

The "QuickWatch" will supports that since at least 10 years


Suppose you have a structure x with a member foo that is a void *
and you want to transform it into a double *

You click in the member, then VStudio will write

x->foo

in the text window at the top. You transform that into:

*(double *)&x->foo

and there you go, you click in "Reevaluate" and you see your double
data.

 

[cpp4ever]

* Pete Becker, on 05.08.2010 16:07:

My bad, I mixed up Boostpro Computing and Roundhouse Consulting.



Well, to Bill Clinton his interpretation of 'is', 'sex' etc. was
presumably obvious.

And so he could honestly claim that he never did have sex with that woman.

He could claim "no sex" like you're claiming that you don't have any
*nix tools installed, and that you're not using them for development of
programs. Nah, I didn't touch that Mona Lewinsky! Was she that touched
me... He he.


Cheers & hth.,

- Alf

has never been a Lewinsky tool, doesn't even know the skill set
required. Secondly are folks here suggesting the old Bill only got a C++
when attempting that job?

cpp4ever

 

[tni]

Miles Bader a écrit :

The "QuickWatch" will supports that since at least 10 years


Suppose you have a structure x with a member foo that is a void *
and you want to transform it into a double *

You click in the member, then VStudio will write

x->foo

in the text window at the top. You transform that into:

*(double *)&x->foo

and there you go, you click in "Reevaluate" and you see your double
data.

There is also 'Add Watch' in the context menu.

If you want to interpret a pointer as array, you can just append
something like ',100' to the watch/quick watch expression (this would
show the first 100 elements).

While I dislike VS, the debugger is light years ahead of the slow,
buggy, worst UI ever GDB.

 

[Öö Tiib]

Am 05.08.2010 13:04, schrieb Öö Tiib:


Sorry, but the Windows developers i known (i have worked with ~100
Windows developers until now), are C++ Programmer (native C++).

Why you are sorry? It may be any reason like for example it is
corporate policy. Like: "Open source? NO!" People using awful things
like MS Source Safe code repository because of such evil fate forces
them are not unheard of. What makes me suspidous is that 2% (one from
50?) who somehow can use Unix tools.

 

[Balog Pal]

Why you are sorry? It may be any reason like for example it is
corporate policy. Like: "Open source? NO!" People using awful things
like MS Source Safe code repository because of such evil fate forces
them are not unheard of. What makes me suspidous is that 2% (one from
50?) who somehow can use Unix tools.

I still didn't get the point from the last round: what is supposed to be so
compelling about the unix toolbox on windoze?

I view it as leftovers from evolution. And they are IMO like the
std::string, generally awful in every way, but it can be expected to exist
in many basic configurations, also you can expect familiarity.

But if a particular environment has *better* stuff? Even if not better,
just more native, should win over, it capable to do the job.

Does using Borland's version of grep on DOS counts as using a unix tool? Or
more interestingly, what about using 'find in files' from Total Connamder?

Or even better: that in Visual Studio?

If Alf counts the last one IN, then there's harly much to talk about. If it
is OUT, I'm interested why would using the suboptimal version count as sign
of incompetency.

(The mentioned toolset was borb what, 25 years ago? Hope no one believes
there are no better alternatives emerged for any particular workflow on any
platform widely used by programmers...)

 

[Alf P. Steinbach /Usenet]

* Balog Pal, on 06.08.2010 13:53:

I still didn't get the point from the last round: what is supposed to be
so compelling about the unix toolbox on windoze?

For example, many C and C++ libraries can't be (practically) installed without
having *nix tools for the installation process: the install script requires
those tools.

That's pretty compelling to me.

I view it as leftovers from evolution. And they are IMO like the
std::string, generally awful in every way, but it can be expected to
exist in many basic configurations, also you can expect familiarity.

But if a particular environment has *better* stuff? Even if not better,
just more native, should win over, it capable to do the job.

Does using Borland's version of grep on DOS counts as using a unix tool?
Or more interestingly, what about using 'find in files' from Total
Connamder?

Or even better: that in Visual Studio?

If Alf counts the last one IN, then there's harly much to talk about. If
it is OUT, I'm interested why would using the suboptimal version count
as sign of incompetency.

(The mentioned toolset was borb what, 25 years ago? Hope no one believes
there are no better alternatives emerged for any particular workflow on
any platform widely used by programmers...)

Regular expressions are seldom the answer...


Cheers & hth.,

- Alf

 

[Balog Pal]

For example, many C and C++ libraries can't be (practically) installed
without having *nix tools for the installation process: the install script
requires those tools.

That's pretty compelling to me.

I'm getting more and more confused.

So let's say I work on some C++ project, that uses some libraries. They
were decided by someone, installed by someone else, added to the build
system outside my work too.

Then in turn, your competency assessment will depend on whether some of
those libraries happen to use certain tools at the moment or not. ;-o

Regular expressions are seldom the answer...

That is irrelevant, the question is whether the mentioned tol usage counts
in or out for your purposes, please pick one. ;-)

 

[Alf P. Steinbach /Usenet]

* Balog Pal, on 06.08.2010 14:36:

I'm getting more and more confused.

So let's say I work on some C++ project, that uses some libraries. They
were decided by someone, installed by someone else, added to the build
system outside my work too.

The question is, could you install them?

Then in turn, your competency assessment will depend on whether some of
those libraries happen to use certain tools at the moment or not. ;-o
No.



That is irrelevant, the question is whether the mentioned tol usage
counts in or out for your purposes, please pick one. ;-)

A person who always used Visual Studio multi-find or always used grep (or
Windows' findstr), choosing the tool irrespective of the task, would be
effectively incompetent. Thus, it's an invalid dilemma: if it is accepted as
valid, then no matter which of the two options is chosen, the person must be
incompetent, someone choosing to struggle needlessly just because of a fixation
on given tool or toolset. A competent person uses the available tools best fit
for a task, acquires such tools, or if necessary creates a suitable tool.

And creating a tool is mostly what the *nix tools are about, namely creating
special purpose tools such as install scripts, or even throwaway one-liners, as
opposed to MS' idea of using canned slightly parameterized functionality.

Canned functionality is good when it's applicable, bad when you need something
even slightly outside its parameters.


Cheers & hth.,

- Alf

 

[jacob navia]

James Kanze a écrit :

The Microsoft debugger has to be the worst I've seen
to date.

Sure

(1) It will show in the "autos" windows, the inetersting variables
automatically. You are now UNABLE to type at EACH step

gdb> print foo_variable

It does it for you without any typing. HORRIBLE.

(2) It shows you in a window the program text. How HORRIBLE.
Now you are unable to type at each step

gdb> list

And you see in good colours the whole module's text without starting
vi in another xterm. HOW HORRIBLE!

(3) And a long list of thousands of features that gdb provides only with
arcane commands that you have to memorize and regurgitate each time
you use it. Not to speak of "go to definition" that gdb does very
well isn't it?

linux people are just blind.

 

[Alf P. Steinbach /Usenet]

* Alf P. Steinbach /Usenet, on 30.07.2010 16:53, about Visual Studio 2010:

Argh.

I now discovered that with Windows XP service pack 3 (yeah, I'm a latecomer)
Microsoft has sabotaged the 'echo' command in the command interpreter.

As background information, in earlier service packs and updates Microsoft has
sabotaged other commands such as 'ftype' (can no longer delete associations),
'netstat' (slows to an excruciating crawl if you ask it for process info),
'openfiles' (behaves erratically, sometimes refusing to list open files), and more.

The 'netstat' thing was, as I recall, partially documented. It was purportedly
in order to close a security hole. But I don't buy that explanation.

Background info on 'echo': 'echo' is an internal command in the Windows command
interpreter, and in MS-DOS it had a bug, that by writing 'echoX', where X is any
special character in a set that the command interpreter parser doesn't actively
check for, you could make 'echo' output a blank line.

A convention was soon established where the special character X was a period,
thus, writing 'echo.' in order to output a blank line, or even 'echo.bah' in
order to output 'bah' and use a single notational convention for 'echo'.

And this convention was documented by Microsoft, even in the Windows XP help
system, but not mentioning the general mechanism by which it worked, the
original MS-DOS bug where any special character X is accepted as delimiter.

Now with XP service pack 3 the documented 'echo.' no longer works:

C:\Documents and Settings\Alf> echo.
'echo.' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Alf> _

However, as far as I can tell all the other special characters X, the
undocumented ones, still work, e.g.

C:\Documents and Settings\Alf> echo Here's a blank line: & echo/ & echo See?
Here's a blank line:

See?

C:\Documents and Settings\Alf> _

Thus, it's not that Microsoft has fixed the original command interpreter parser
bug. They have specifically and apparently /deliberately/ made the documented
'echo.' NOT work, breaking a lot of batch files. While leaving the original bug.

Grrr!


- Alf

 

[Balog Pal]

A person who always used Visual Studio multi-find or always used grep (or
Windows' findstr), choosing the tool irrespective of the task, would be
effectively incompetent. Thus, it's an invalid dilemma: if it is accepted
as valid, then no matter which of the two options is chosen, the person
must be incompetent, someone choosing to struggle needlessly just because
of a fixation on given tool or toolset. A competent person uses the
available tools best fit for a task, acquires such tools, or if necessary
creates a suitable tool.

Ah, now we're getting somewhere.

And creating a tool is mostly what the *nix tools are about, namely
creating special purpose tools

Well, sort of.
The said tools are (mostly) not good for anything alone. So indeed they are
there as lego elements building something else.

But that does not imply that they do any particularly good job for a task.
That is what I said elsewhere -- for windows you can obtain way more
assembled tools so there is less reason to build your own. Also the programs
around development are much better to cover the regular workflows. And for
tool building there are also elements that are not worse.

For that reason compenency is better measured with the primary values (from
the quote on top), without mentioning any particular tool or technlogy as a
marker.

such as install scripts, or even throwaway one-liners, as opposed to MS'
idea of using canned slightly parameterized functionality.

Huh? MS won most of the marked by making abot ALL its tools *scriptable*.
From quite the beginning. MS Word for dos had cool macros and not that
cool, still usable language. Then Winword introduced the superior WordBasic
in the first version, with full access to stuff well beyond just the text.
Then it evolved to general VBA uniformly usable the same way with all its
tools.

Hope you don't want to compare abilities and the mundane "language' of
whichever unix shell with it...

Canned functionality is good when it's applicable, bad when you need
something even slightly outside its parameters.

Sure, but having a rich canned functionality in company of powerful and
universal means to call into anything is IMNSHO superior to having just
basic bricks and a supposed glue that was hacked together without much
thought to either desing or implementation. (that unix shell went so to the
extreme to inspire the IOCCC...)

 

[Balog Pal]

James Kanze a écrit :

Sure

(1) It will show in the "autos" windows, the inetersting variables
automatically. You are now UNABLE to type at EACH step

gdb> print foo_variable

It does it for you without any typing. HORRIBLE.

BAH, actually it spoils even the fun to be "that horrible": you open the
command window, and can type ? foo_variable along with many other commands,
and even define your own aliases so ? is porbably replaceable to print...
;-)

 

[Vladimir Jovic]

James Kanze a écrit :

Sure

(1) It will show in the "autos" windows, the inetersting variables
automatically. You are now UNABLE to type at EACH step

gdb> print foo_variable

It does it for you without any typing. HORRIBLE.

(2) It shows you in a window the program text. How HORRIBLE.
Now you are unable to type at each step

gdb> list

And you see in good colours the whole module's text without starting
vi in another xterm. HOW HORRIBLE!

(3) And a long list of thousands of features that gdb provides only with
arcane commands that you have to memorize and regurgitate each time
you use it. Not to speak of "go to definition" that gdb does very
well isn't it?

Yes, I agree it is bad.
But I see you haven't tried a linux GUI debugger. You know - there are
such things.
btw isn't there a windows command line debugger. I think there was long
time ago

linux people are just blind.

Cool, it turns into a windows vs linux Both have their pros and cons,
but in my opinion linux is wining (free, more stable, less viruses, less
powerful machine needed). This battle will never end, since they all got
fanboys.

Before you respond, take a look at this :
http://images.encyclopediadramatica.com/images/9/97/Macfagswinfagslinuxfags.jpg

 

[Balog Pal]

I now discovered that with Windows XP service pack 3 (yeah, I'm a
latecomer) Microsoft has sabotaged the 'echo' command in the command
interpreter. ....
Now with XP service pack 3 the documented 'echo.' no longer works:

C:\Documents and Settings\Alf> echo.
'echo.' is not recognized as an internal or external command,
operable program or batch file.

On my machine it works:

D:\in>type alf.cmd
echo off
echo %1
echo.
echo foo
echo .



D:\in>alf bar

D:\in>echo off
bar

foo
..

And typing echo. directly also creates an empty line.


XP Pro SP3 32 bit, with updates to last week.

Thus, it's not that Microsoft has fixed the original command interpreter
parser bug. They have specifically and apparently /deliberately/ made the
documented 'echo.' NOT work, breaking a lot of batch files. While leaving
the original bug.

Grrr!

I wouldn't bet on that. Can't it be an artefact from some
international/lang settings on your machine? Maybe the dot you enter is
really some other character that just looks alike?

 

[Balog Pal]

Yes, I agree it is bad.
But I see you haven't tried a linux GUI debugger.

Please, PLEASE point me to a well working GUI debugger for ubuntu lucid.

You know - there are such things.

Yes, as I said upstream, ddd used to work on fedora with just gdb crashes
every 20 minutes. On lucid it is trash right from the start, but if you open
the data window it captures the input and you must ssh in from outside for a
pkill... The other stuff i found as gdb frontend on google didn't get even
that far.

 

[Francesco S. Carta]

* Alf P. Steinbach /Usenet, on 30.07.2010 16:53, about Visual Studio 2010:


I now discovered that with Windows XP service pack 3 (yeah, I'm a
latecomer) Microsoft has sabotaged the 'echo' command in the command
interpreter.

For what is worth, in my Windows 7 copy the echo command works fine
(fine in the sense that it accepts the "echo." command):

-----------------------------
Microsoft Windows [Versione 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati.

C:\Users\Admin>type test.bat
@echo off
echo.start
echo.
echo.in
echo.
echo.stop
echo on
C:\Users\Admin>test.bat
start

in

stop

C:\Users\Admin>

 

[Alf P. Steinbach /Usenet]

* Balog Pal, on 06.08.2010 16:13:

On my machine it works:

D:\in>type alf.cmd
echo off
echo %1
echo.
echo foo
echo .



D:\in>alf bar

D:\in>echo off
bar

foo
.

And typing echo. directly also creates an empty line.


XP Pro SP3 32 bit, with updates to last week.


I wouldn't bet on that. Can't it be an artefact from some
international/lang settings on your machine? Maybe the dot you enter is
really some other character that just looks alike?

Nope.

And it's worse:


<example>
C:\Documents and Settings\Alf> echo,


C:\Documents and Settings\Alf> echo,Comma
Comma

C:\Documents and Settings\Alf> echo;Semicolon
Semicolon

C:\Documents and Settings\Alf> echo:Colon
Colon

C:\Documents and Settings\Alf> echo\Backslash
Backslash

C:\Documents and Settings\Alf> echo/Forward slash
Forward slash

C:\Documents and Settings\Alf> echo?Query
'echo?Query' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Alf> echo(Lefparens
Lefparens

C:\Documents and Settings\Alf> echo)Rightparens
'echo)Rightparens' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Alf> echo=Equals
Equals

C:\Documents and Settings\Alf> echo#Hash
'echo#Hash' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Alf> echo!Bang
'echo!Bang' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Alf> echo.Dot
Dot

C:\Documents and Settings\Alf> echo.
'echo.' is not recognized as an internal or external command,
operable program or batch file.

C:\Documents and Settings\Alf> _
</example>


Thus, they have not fixed the original bug allowing e.g. comma, they have not
disabled the (documented) dot as separator in general, they have disabled the
*particular usage* that was documented, namely the string "echo." as command.

Jeez.


Cheers, & thanks for double-checking (don't know what's different),

- Alf

 

[Vladimir Jovic]

Please, PLEASE point me to a well working GUI debugger for ubuntu lucid.

imo from ubuntu 8.04 was good, but after that it started going downhill,
and the lucid is the worst. Just try to install kdevelop on it, without
enabling backports and unsupported packages.

Yes, as I said upstream, ddd used to work on fedora with just gdb
crashes every 20 minutes. On lucid it is trash right from the start, but
if you open the data window it captures the input and you must ssh in
from outside for a pkill... The other stuff i found as gdb frontend on
google didn't get even that far.

I am using fedora 9, and ddd works fine. (yes, I am aware it is super old)
Haven't tried ddd on something newer, but I am not running debugger very
often. I mostly rely on unit tests.