[OT] Grumble...

[Dilip]

And?  If you don't have access to any of the tools necessary to
do the job, you don't develop serious software.

Let's be honest about this.  If you're doing all the work,
rather than writing simple scripts to do much of it, then you're
wasting a lot of your time.  For simple, repetitive tasks, the
machine is a lot better than you are.

I must have somehow got into people's killfile without ever having
posted so much in the NG, but I will persist. James, this "scripting
tasks" that you keep talking about, have you ever considered writing
them with Powershell? MSBuild is Microsoft's version of Ant and you
can invoke Powershell scripts from that and perform whatever the heck
you want. Powershell can also be used to write repetitive tasks the
Ian Collins asked about in another thread. I noticed another poster
named Ralph also mentioned this elsethread but expectedly that wasn't
taken up either. Is there simply a refusal to look at what is
available on Windows and simply parrot Cygwin as a solution to any
problem?

 

[Dilip]

Because it doesn't work.  (At least the one in Visual Studios is
completely broken with regards to dependency analysis; it does
the dependency analysis *before* the pre-build steps---which of
course modify files which should trigger additional
recompilations.)

and btw, until VS 2008 it wasn't possible to build VC++ projects using
MSBuild (I think.. I am not 100% sure about this). But as of VS 2010,
that restriction is removed. see this:
http://msdn.microsoft.com/en-us/library/ee662426.aspx

My point is MSBuild is much powerful build system and its easy to use
some automated daily build framework like CruiseControl.NET to invoke
MSBuild tasks if you have projects with complex dependencies and
modules.

 

[Rolando Pereira]

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.

Can't you use "display foo_variable" on the gdb prompt? It should
always display the value of foo_variable at every step.

(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!

Do you know that gdb ships with a text user interface that uses
windows?

Start gdb with the flag "-tui" or use the command "gdbtui" on the
shell (You can also use Ctrl-x a to toggle this mode on/off while
running gdb).

Unfortunately it doesn't do syntax highlight, although you can use
"cgdb" to get that (I've found out that the lack of syntax highlight
doesn't really bother me that much, but then again, I'm still a
student).

(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?

Yeah, I got nothing there. I guess you can use the "help" command to
see the commands that gdb uses, or you can define your own commands
using a .gdbinit, but I can understand that its usually not an
option. I usually just use a .gdbinit file that I've found on the
Internet that defines a few commands to pretty-print a couple of
data structures (for example, std::vector) instead of the usual dump
of information that gdb does (I've heard that the newer versions of
gdb work better at displaying the data structures, but I haven't
tried them yet).

You can find that .gdbinit here:
http://www.cs.tau.ac.il/telux/lecture-notes/gdbinit_stl_views-1.03.txt

Regarding the "go to definition" I think that's part of the IDE? For
example, if I recall correctly the C++ plugin for Eclipse uses gdb as
the debugger and it has no problem using the "go to definition"
command of Eclipse.

Hmm... While I was writing this, I learned that gdb does allow one to
say for example "list <class-name>" and it shows the definition of the
class (on the window if you use the tui mode or on the prompt if you
don't use it).

It seemed to work pretty well on a small code base I have here, but
I'm not sure if it would work as you want on a large code base.

(By the way, do you know you can just type "l" as a shortcut to
"look"?)

For those who want to compare, here the output of my "gdb -v":

GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".

linux people are just blind.

Meh, just like windows, there are people from several walks of life
using linux, so I guess you get a bit of everything when interacting
with them .

 

[jacob navia]

Rolando Pereira a écrit :

Can't you use "display foo_variable" on the gdb prompt? It should
always display the value of foo_variable at every step.

That's even MORE typing since you have to add and delete those displays
at each time. You arfe normally not interested in "foo_variable" ALWAYS.
Just when its getting assigned or appears in the expression being executed!

Normal debuggers FIGURE OUT THEMSELVES the variables that are
inetersting.

The mere fact that you do not figure out this shows how hopeless
outdated your "debugger experience" is.

Do you know that gdb ships with a text user interface that uses
windows?

Sorry, doesn't work in my setup

Start gdb with the flag "-tui" or use the command "gdbtui" on the
shell (You can also use Ctrl-x a to toggle this mode on/off while
running gdb).

Unfortunately it doesn't do syntax highlight, although you can use
"cgdb" to get that (I've found out that the lack of syntax highlight
doesn't really bother me that much, but then again, I'm still a
student).

I know that. One of the (many) obvious bugs is that it doesn't clean up
the screen and after a few steps your screen is completely GARBLED.
After gdb finishes, if you restart without quitting gdb you will see a
mixture of new stuff and old text lines. This happens very often for
other unknown reasons...

Besides, the text output of your program will show in the source editor,
that doesn't clear after any text output, so if your program does
any text output your screen will be garbled

This is one of the best examples of the incredible sophistication of
GNU tools.

 

[jacob navia]

Dilip a écrit :

I must have somehow got into people's killfile without ever having
posted so much in the NG, but I will persist. James, this "scripting
tasks" that you keep talking about, have you ever considered writing
them with Powershell? MSBuild is Microsoft's version of Ant and you
can invoke Powershell scripts from that and perform whatever the heck
you want. Powershell can also be used to write repetitive tasks the
Ian Collins asked about in another thread. I noticed another poster
named Ralph also mentioned this elsethread but expectedly that wasn't
taken up either. Is there simply a refusal to look at what is
available on Windows and simply parrot Cygwin as a solution to any
problem?

There is no blinder person as the man that doesn't want to see...

 

[Balog Pal]

There is no blinder person as the man that doesn't want to see...

just for the record, you don't have to infest your machine with the cygwin
nightmare just to us the toolset, as the whole pack is available in native
WIN32 build at sourceforge:

http://sourceforge.net/projects/unxutils/files/unxutils/current/UnxUtils.zip/download

and there are really native versions that for example understand * patterns
themselves.

It really beats me how people who are actually capable of writing software
of any (working) kind can stumble on the problem of "repeating tasks".
using just anything at hand or writing.

Extracting file list right from the .vcproj is a fine idea, but I never did
that as my sources are organized in folders anyway. And running a command
against them can be done just by the simple *.cpp match in the folders.

And needs no program, just the for command:

for %x in (*) do call whatever.bat "%x"

(if used inside a .bat file, %%x instead of %x). Adding a /R processes the
whole tree or with /D can walk dirs. 'help for' to see more options.

The simple version worked back in DOS 3.3, probably earlier too.

It is capable to invoke stuff on processing text... what would solve James'
problem (IUC) without installing CW.

 

[Alf P. Steinbach /Usenet]

* Balog Pal, on 08.08.2010 00:34:

just for the record, you don't have to infest your machine with the
cygwin nightmare just to us the toolset, as the whole pack is available
in native WIN32 build at sourceforge:

http://sourceforge.net/projects/unxutils/files/unxutils/current/UnxUtils.zip/download

Yes, I have them.

Also have cygwin.

And Interix, that is, Microsoft's services for Unix (it's amazing that Microsoft
distributes g++, but there you are), although current uninstalled.

and there are really native versions that for example understand *
patterns themselves.

It really beats me how people who are actually capable of writing
software of any (working) kind can stumble on the problem of "repeating
tasks". using just anything at hand or writing.

Extracting file list right from the .vcproj is a fine idea, but I never
did that as my sources are organized in folders anyway. And running a
command against them can be done just by the simple *.cpp match in the
folders.

And needs no program, just the for command:

for %x in (*) do call whatever.bat "%x"

(if used inside a .bat file, %%x instead of %x). Adding a /R processes
the whole tree or with /D can walk dirs. 'help for' to see more options.

The simple version worked back in DOS 3.3, probably earlier too.

It is capable to invoke stuff on processing text... what would solve
James' problem (IUC) without installing CW.

I think it is an interesting exercise to count lines of source code using
Windows' 'for'. Yes, it's doable. But as opposed to using *nix 'wc'.

The following illustrates, IMHO, the Microsoft versus *nix philosophy difference
(use like 'xxxsplit %path%'):


<code file="winsplit.bat">
@echo off
for /f "tokens=1* delims=;" %%p in ("%*") do (
echo %%p
winsplit %%q
)
</code>


<code file="nixsplit.bat">
@echo %* | tr ';' '\012'
</code>


Cheers,

- Alf

 

[Öö Tiib]

Just for the record, Visual Studios 2005 (the version we use
officially) does NOT handle all of the dependencies correctly.
We've had to impose a rule that in certain cases, you must click
on build twice, because the first build will ignore the
dependencies generated by the pre-build step.

You may also impose the rule that you use makefile for building C or C+
+ (i have heard rumor that Microsoft uses such rule in house).

Or Python (I suspect).  In my case, I learned all this before
there was perl or python, so I use the Bourne shell and the Unix
tool kit.  We have imposed perl on all of our development
machines, however, and scripts I export, I have to rewrite in
perl.

Yes and/or something functionally close to sed is probably writable in
Visual Basic. Sounds irrational to rewrite a well-tested unix utility
(from seventies) that is freely down-loadable as open source gnuwin32
port, but it may be fun and educating to reinvent the wheels
sometimes.

 

[joe]

More generally: I'm currently working in a Windows shop, with a
lot of Windows and Visual Studios experts around me, so I have
the occasion to see how things are done. For somethings, I was
surprised: I've watched one or two of the people editing with
VS, for example, and the cursor and text were flying around just
as they do when I'm editing with vim, without any time being
lost having to reach for the mouse.

I have "stupid" "hiring policies". I see that, they don't get the job.
(But I know, I do things quite differently than "the status quo").

I don't know how to do this
with the Visual Studios editor

And/but you want to? I understand, Mr. OldSkool. I bet you drive a Harley
too? Have anywhere to go on it? Do tell (nah, let's keep the room
TECHNICAL chat only... that's safe).

---I've got vi in my fingers

I can't help but feel sorry for you (?).

---but
apparently, it's possible. On the other hand, I'm constantly
getting questions about repeating tasks (like running an in
house pre-processor over a set of files) for which the only
answer I can give is: "if you have CygWin installed...".

I don't understand all of this CygWin banter. A decade (I wish it was
just that!) or so ago, maybe, but about a decade ago, the Ming stuff (I
don't use it, but remember it from history, so I don't know what the
actual name is... MingGW???? I dunno, don't care either) became available
and people are still emulating ... what?! CygWin? Surely you all jest!
Are those talking about CygWin what is left of foolish thoughts of Unix
and Windows intersecting?? And don't you all know set theory (is it
"theory"? I'm not a mathematician.) The intersection is not "small", it's
the empty set!

And
I'm getting the questions because the Windows experts don't know
how to do this with standard Windows tools. (In many cases, the
CygWin solution involves reading and parsing the solution and
project files. It sort of surprises Windows people that you can
actually extract filenames from a project file, and use them as
arguments to a command, at the command line.)

This highly-detailed discussion "surprises" (if not bores) me. But,
nevermind, I don't want to know (how YOU ALL wasted your time).

 

[joe]

(e-mail address removed):
[...]

More generally: I'm currently working in a Windows shop, with a
lot of Windows and Visual Studios experts around me, so I have
the occasion to see how things are done. For somethings, I was
surprised: I've watched one or two of the people editing with
VS, for example, and the cursor and text were flying around just
as they do when I'm editing with vim, without any time being
lost having to reach for the mouse. I don't know how to do this
with the Visual Studios editor---I've got vi in my fingers---but
apparently, it's possible.

Yes. In principle in Windows one could often get away without ever
touching a mouse (this might be a reminiscent from early Windows times
when having a mouse was not obligatory), whereas in X-Windows some
tasks seem to be mouse-only most of the time (e.g. copy-paste in many
programs, regrettably).

"The song remains the same" (!): commandline vs. GUI. "Pick your poison",
I guess.

 

[joe]

Do be able to do any reasonable development work.

Pfft. Strawman (or worse?).

For example, I've recently seen

Because it doesn't work. (At least the one in Visual Studios is
completely broken with regards to dependency analysis; it does
the dependency analysis *before* the pre-build steps---which of
course modify files which should trigger additional
recompilations.)

I assure you it is a detail. Not to diss the details, but "I digress"
(?).

How many portable libraries have you written?

Heads up people! The "key" word was the HOLY trait, "portability". Now
THAT and less than a dime WILL get you MUCH MORE than a cup of coffee (if
you are so inclined).

How do you solve
portability issues otherwise?

Oh, the "is there a god" debate in other "clothes". So let it be written!

automake and company are far from
perfect, but they do work, which is more than I can say for most
of the other tools I've seen.


And? If you don't have access to any of the tools necessary to
do the job, you don't develop serious software.

Said "THE commandline" (you had me fooled! I though you were a real
person 'til now! Bot alert (!), JK **IS** "the" commandline!!!

Let's be honest about this.

L-O-L! (And there is wonder why people don't vote?).

If you're doing all the work,
rather than writing simple scripts to do much of it, then you're
wasting a lot of your time. For simple, repetitive tasks, the
machine is a lot better than you are.

No comment. (read, learn it yourself).

 

[joe]

Dilip a écrit :

There is no blinder person as the man that doesn't want to see...

"You speak with forked tongue". People, he speaks with forked tongue. (Or
I "credit" (quotes important) him with being smarter than he is. If not
so, then not so.)

 

[joe]

Yes, I have them.

Also have cygwin.

And you admit it even. Quite forthright of you Alf. I know your hardship.
(No I don't, I was just feigning).

 

[joe]

This is one of the best examples of the incredible sophistication of
GNU tools.

You best stick with C, old man: it's not your father's C++.

 

[Öö Tiib]

I must have somehow got into people's killfile without ever having
posted so much in the NG, but I will persist.  

James, this "scripting
tasks" that you keep talking about, have you ever considered writing
them with Powershell?  MSBuild is Microsoft's version of Ant and you
can invoke Powershell scripts from that and perform whatever the heck
you want.  Powershell can also be used to write repetitive tasks the
Ian Collins asked about in another thread.  I noticed another poster
named Ralph also mentioned this elsethread but expectedly that wasn't
taken up either.  Is there simply a refusal to look at what is
available on Windows and simply parrot Cygwin as a solution to any
problem?

Why indeed some stupid parrots pick unix script and utilities and
other stupid parrots use python or perl?

Can not there be that these things:
1) do not change their behavior or performance in major mysterious way
with next windows service pack or security update;
2) do not mysteriously disappear from or suddenly start throwing up
showstopper message-boxes in middle of running on next "vista";
3) often do it faster;
4) with minor changes/care even run on linux, os-x, solaris etc?

What makes you think that the powershell is not yet another "visual
basic 6.0"? Is its functionality standardized somewhere and
interpreters source code up in SourceForge?

 

[Sousuke]

For doing *ALL* the work that is needed to be done automatically. No
manual copying/pasteing, no manual rerunning third party tools, no
manual editing generated files or xml-s. Everything that can be
automated should be automated. You are software developer. So you
never have to do same thing over 100 times.


Maybe you are unaware of *ALL* the build tasks that need to be done.
Perl is one way how to make it possible.

Lets for example say that you have third party code generator that
generates 5% of the C++ code in project using .foo files and .h files.
Do you know how to add such .foo files to VS 2010 build system in a
way that each time .foo file (or dependant .h file) is changed it does
rerun that code generator for incremental build?

Ok, lets say that above-described code generator generates code mostly
OK, but does not take some peculiarity of microsoft into account (some
posix function was prefixed with underline by MS). Now you obviously
write a little script that both calls that code-generator and
afterprocesses the produced code so underlines are added where
needed.

Can you write such program as batch file? No? So what you do?

I've never needed to do that. So ok, that would be one reason to use
scripts.

But it's well beyond the realm of "building" a project and sounds more
like an exotic requirement.

Who cares what you doubt? If the institution that ordered the work did
demand that security schemes are handled by using exactly that library
and pays bigger bucks than you have ever held in hand, then we use
that library no doubt. - Hide quoted text -

If the decision to use it is out of my control, then that's a separate
problem. But it doesn't mean that I wouldn't still doubt its
quality

 

[Sousuke]

Why indeed some stupid parrots pick unix script and utilities and
other stupid parrots use python or perl?

Can not there be that these things:
1) do not change their behavior or performance in major mysterious way
with next windows service pack or security update;
2) do not mysteriously disappear from or suddenly start throwing up
showstopper message-boxes in middle of running on next "vista";
3) often do it faster;

Scripting languages are generally slow. For the tasks in question, the
speed of the scripts would be negligible compared to the speed of the
actual compilation and I/O.

4) with minor changes/care even run on linux, os-x, solaris etc?

What makes you think that the powershell is not yet another "visual
basic 6.0"? Is its functionality standardized somewhere

No Unix-ish scripting language I know of (Perl, Python, AWK, etc.) is
standardized either.

Besides, I don't see why that matters. C++ for example wasn't
standardized until 1998, yet its most thriving time was probably
before that.

and
interpreters source code up in SourceForge?

I don't see why that matters either.

Your other points also seem pretty baseless.

 

[Ian Collins]

I've never needed to do that. So ok, that would be one reason to use
scripts.

But it's well beyond the realm of "building" a project and sounds more
like an exotic requirement.

You would be surprised how common a requirement it is. Every major
project I've worked on involved some form of code generation. This can
normally be managed within a makefile. Life gets more interesting when
the tools used generate the makefile (or whatever the platform uses)
under the hood and the user can't tweak them.

 

[Rolando Pereira]

Rolando Pereira a écrit :

That's even MORE typing since you have to add and delete those displays
at each time. You arfe normally not interested in "foo_variable" ALWAYS.
Just when its getting assigned or appears in the expression being executed!

Normal debuggers FIGURE OUT THEMSELVES the variables that are
inetersting.

I don't understand this. When I used Eclipse (don't have it
installed on this machine so I can't confirm it) you could access
the value of the variables by placing the mouse cursor over the
variable that you wanted, or see the local and global variables on a
separated window.

The mere fact that you do not figure out this shows how hopeless
outdated your "debugger experience" is.

Like I said, I'm still a student, so we probably just have different
usercases and requirements for our tools. Nothing wrong with that I
think. It's not like the fact that gdb exists will somehow make
Visual Studio debugger work in strange and unique ways .

Sorry, doesn't work in my setup

What is the version of your gdb?

Besides, the text output of your program will show in the source editor,
that doesn't clear after any text output, so if your program does
any text output your screen will be garbled

This is one of the best examples of the incredible sophistication of
GNU tools.

On emacs you can use the command gdb-use-separate-io-buffer if you
want the io of your program to go to a different window.

On the end of the day, they're just different tools and both have
advantages and disadvantages. For example, once I had to debug a
program on a remote server using ssh. In that case I had to use
gdb. I also have had to debug a program on a local machine. In that
case I use a more graphical debugger (depends on what IDE is
installed on that machine).

Neither one of them are the Holy Grail of debuggers, there is
always room for improvement.

Disclaimer: On the few times I've had to use Visual Studio, I didn't
use the debugger, so if it does something mind-blowing I probably
don't know about it.

 

[jacob navia]

joe a écrit :

You best stick with C, old man: it's not your father's C++.

What should that mean Mr?


It hurts when somebody criticizes GNU?

Well, that was the intent. To show how crappy GNU tools can be.

And yes, I stick to C. And what my age is concerned... I hope that
doesn't ever happen to you.

I just hope you do not get old at all.