I am looking into setting up VACPP v3.08. I had this installed on a previous computer and I still have the VACPP files from the installation on that system.
Hoping to avoid re-installing from scratch (including the various patches), I'm wondering if it is possible to just copy the files and set the relevant environment variables to get a functional VACPP.
I undersand that a) no objects will be created; b) no asscoiations will be created; and c) the Workframe portion will not work since it requires creating various WPS object classes. But other than this are there reasons to think that just copying files and setting variables would not work?
> I am looking into setting up VACPP v3.08. I had this installed on a
> previous computer and I still have the VACPP files from the
> installation on that system.
> Hoping to avoid re-installing from scratch (including the various
> patches), I'm wondering if it is possible to just copy the files and
> set the relevant environment variables to get a functional VACPP.
> I undersand that a) no objects will be created; b) no asscoiations
> will be created; and c) the Workframe portion will not work since it
> requires creating various WPS object classes. But other than this are
> there reasons to think that just copying files and setting variables
> would not work?
Test it! No one can say exactly which components of VACPP depends on further registrations. Maybe the debugger works, maybe only mostly, and so on. Note that files might be placed in system directories by the installer as well.
What you can do is, install VACPP 3 normally and then replace the files with patch 3.08. This will work.
> Hoping to avoid re-installing from scratch (including the various > patches), I'm wondering if it is possible to just copy the files and > set the relevant environment variables to get a functional VACPP.
As Marcel suggested, try it. Without the WPS bits, VAC is just another command line compiler toolchain.
FWIW, it's possible to get everything working, including the WPS bits,
but that takes some planning and the right tools. What I used was Object Desktop's Object Packager to create a package that could be moved to the other system. Restoring the package also registered all the WPS classes.
Steve
-- ---------------------------------------------------------------------
Steven Levine <stev...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.comwww.ecomstation.com ---------------------------------------------------------------------
> I am looking into setting up VACPP v3.08. I had this installed on a > previous computer and I still have the VACPP files from the > installation on that system.
> Hoping to avoid re-installing from scratch (including the various > patches), I'm wondering if it is possible to just copy the files and > set the relevant environment variables to get a functional VACPP.
> I undersand that a) no objects will be created; b) no asscoiations > will be created; and c) the Workframe portion will not work since it > requires creating various WPS object classes. But other than this are > there reasons to think that just copying files and setting variables > would not work?
I've been doing it for years since my CD became unreadable. I did not
really ever use the icons that were created and just used the command line functions so I did not even try to bring them across so can't say
about those but both 3.08 and 3.65 have been copied across and I just use the setup scripts (no config.sys changes for it here).
Andy
--
On Tue, 25 Sep 2012 15:45:12 UTC, "John Small" <jsm...@os2world.net> wrote:
> I am looking into setting up VACPP v3.08. I had this installed on a > previous computer and I still have the VACPP files from the > installation on that system.
> Hoping to avoid re-installing from scratch (including the various > patches), I'm wondering if it is possible to just copy the files and > set the relevant environment variables to get a functional VACPP.
Sure. I did that; I got the desktop stuff working too, actually, with a little prior planning.
Update CONFIG.SYS with the following, replacing E:\Development\IBMCPP with the correct path. (Watch out for extraneous line breaks in this post.)
LIBPATH=E:\Development\IBMCPP\DLL;
SET PATH=E:\Development\IBMCPP\BIN;E:\Development\IBMCPP\HELP;E:\Development\IB MCPP
\SMARTS\SCRIPTS;
SET DPATH=E:\Development\IBMCPP\HELP;E:\Development\IBMCPP;E:\Development\IBMCP P\LO
CALE;E:\Development\IBMCPP\MACROS;E:\Development\IBMCPP\BND;
SET HELP=E:\Development\IBMCPP\HELP;
SET BOOKSHELF=E:\Development\IBMCPP\HELP;
SET LIB=E:\Development\IBMCPP\LIB;
SET INCLUDE=E:\Development\IBMCPP\INCLUDE;E:\Development\IBMCPP\INCLUDE\SOM;
SET SMINCLUDE=E:\Development\IBMCPP\INCLUDE;E:\Development\IBMCPP\INCLUDE\SOM;
SET VACPP_SHARED=FALSE
SET CPPHELP_INI=C:\OS2\SYSTEM
SET CPPLOCAL=E:\Development\IBMCPP
SET CPPMAIN=E:\Development\IBMCPP
SET CPPWORK=E:\Development\IBMCPP
SET LOCPATH=E:\Development\IBMCXXO\locale;E:\Development\IBMCPP40\Runtime\local e;E:
\Development\IBMCPP\LOCALE
SET IWFHELP=IWFHDI.INF
SET IWFOPT=E:\Development\IBMCPP
SET IWF.DEFAULT_PRJ=CPPDFTPRJ
SET IWF.SOLUTION_LANG_SUPPORT=CPPIBS30;ENG
SET THREADS=512
SET VBPATH=.;E:\Development\IBMCPP\DDE4VB
SET TMPDIR=E:\Development\IBMCPP\TMP
SET LXEVFREF=EVFELREF.INF+LPXCREF.INF
SET LXEVFHDI=EVFELHDI.INF+LPEXHDI.INF
SET LPATH=E:\Development\IBMCPP\MACROS
SET CODELPATH=E:\Development\IBMCPP\CODE\MACROS;E:\Development\IBMCPP\MACROS
SET CLREF=CPPCLRF.INF+CPPDAT.INF+CPPAPP.INF+CPPWIN.INF+CPPCTL.INF+CPPADV.INF+CP P2DG
INF+CPPDDE.INF+CPPDM.INF+CPPMM.INF+CPPCLRB.INF
-------8<--------8<--------8<--------8<--------8<--------8<-------
> > I am looking into setting up VACPP v3.08. I had this installed on a > > previous computer and I still have the VACPP files from the > > installation on that system.
> > Hoping to avoid re-installing from scratch (including the various > > patches), I'm wondering if it is possible to just copy the files and > > set the relevant environment variables to get a functional VACPP.
> Sure. I did that; I got the desktop stuff working too, actually, > with a little prior planning.
> Update CONFIG.SYS with the following, replacing E:\Development\IBMCPP > with the correct path. (Watch out for extraneous line breaks in this > post.)
1) This is for VACPP 3.08, correct?
2) I was thinking of putting as little as possible in CONFIG.SYS and putting all the others into a CMD file I would run when I am about to use VACPP. The DEVICE statement, if used, clearly would need to be in CONFIG.SYS. And I suspect that the THREADS statement, if used, would also need to be in CONFIG.SYS. If I change the LIBPATH to SET BEGINLIBPATH, how many of the other statements could be put in a CMD file instead of CONFIG.SYS?
> DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS
1) What is this for? I did not have such a statement in my previous CONFIG.SYS.
2) If I use this statement. does it mean I must include all the other statements in CONFIG.SYS, too (so that the driver can find things)?
> SET CPPHELP_INI=C:\OS2\SYSTEM
Is there a reason this has to be a system directory? Could it point somewhere else?
> SET THREADS=512
1) I assume that a higher value, which is already in my current config.sys, would be acceptable.
2) I have several config.sys files from other installations and most use
THREADS=number
instead of SET THREADS=number
Is the "SET" optional? (Does this mean than THREADS is a pseudo env. variable?)
3) Does this statement have to be in CONFIG.SYS to mean anything?
> 1) I assume that a higher value, which is already in my current > config.sys, would be acceptable.
> 2) I have several config.sys files from other installations and most > use
> THREADS=number
> instead of > SET THREADS=number
> Is the "SET" optional? (Does this mean than THREADS is a pseudo env. > variable?)
> 3) Does this statement have to be in CONFIG.SYS to mean anything?
Years ago, I remember looking at this. The details are a little fuzzy,
but:
SET THREADS=512 is something that VAC308 uses to contriol how many threads it will try to use. This needs to be "seen" by VAC308, when it
runs, and it can be in a launch script, instead of in CONFIG.SYS.
THREADS=1024 is something that OS/2 uses to control the number of threads that are available for all programs to use. This must be in CONFIG.SYS.
I would assume, that VAC308 is trying to eliminate the possibility that it might use up all of the threads, leaving everything else in limbo.
HTH
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
On Thu, 27 Sep 2012 12:42:05 +0000 (UTC), John Small <jsm...@os2world.net>
wrote:
> 2) I was thinking of putting as little as possible in CONFIG.SYS and > putting all the others into a CMD file I would run when I am about to > use VACPP. The DEVICE statement, if used, clearly would need to be in > CONFIG.SYS. And I suspect that the THREADS statement, if used, would > also need to be in CONFIG.SYS. If I change the LIBPATH to SET > BEGINLIBPATH, how many of the other statements could be put in a CMD > file instead of CONFIG.SYS?
Most of it can go in a batch file. I reckon "SET THREADS" should be just
"THREADS". It's barely needed anyway as nothing relating to the compiler
is going to use anything like that number anyway.
Just ignore what Bissett says. He know nothing, not being (by his own
admission) a systems programmer.
>> DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS
> 1) What is this for? I did not have such a statement in my previous > CONFIG.SYS.
Something related to the Performance Analyzer IIRC. You can do without
it, but it has no noticable impact if you just leave it in.
> 2) If I use this statement. does it mean I must include all the other > statements in CONFIG.SYS, too (so that the driver can find things)?
>> SET CPPHELP_INI=C:\OS2\SYSTEM
I suspect that is to do with the WPS stuff. I never installed it.
I would theink the command line compiler parts wouldn't need it as they
have no use for any such stuff.
> Is there a reason this has to be a system directory? Could it point > somewhere else?
Presumably, otherwise why make it configurable?
>> SET THREADS=512
> 1) I assume that a higher value, which is already in my current > config.sys, would be acceptable.
Obviously.
> 2) I have several config.sys files from other installations and most > use
> THREADS=number
> instead of > SET THREADS=number
> Is the "SET" optional? (Does this mean than THREADS is a pseudo env. > variable?)
No, it has to be just THREADS.
> 3) Does this statement have to be in CONFIG.SYS to mean anything?
On Thu, 27 Sep 2012 15:14:59 +0000 (UTC), Doug Bissett
<dougb007!S...@telus.net> wrote:
> Years ago, I remember looking at this. The details are a little fuzzy,
> but:
> SET THREADS=512 is something that VAC308 uses to contriol how many > threads it will try to use. This needs to be "seen" by VAC308, when it
> runs, and it can be in a launch script, instead of in CONFIG.SYS.
I smell some more Bissett Bullshit.
I've never had any such statement in my CONFIG.SYS and VAC has always
been fine. Why do you expect a compiler to use hundreds of threads
anyway?
You don't have to answer that one. I know you don't know the answer.
> I was thinking of putting as little as possible in CONFIG.SYS
Verify the file VACPP.PKG in your backupped files. For example, it seems SET THREADS=512 is REM'med out in CSETENV.CMD if you had it in your CONFIG.SYS. You may want to remove the REM then.
> > Years ago, I remember looking at this. The details are a little fuzzy,
> > but:
> > SET THREADS=512 is something that VAC308 uses to contriol how many > > threads it will try to use. This needs to be "seen" by VAC308, when it
> > runs, and it can be in a launch script, instead of in CONFIG.SYS.
> I smell some more Bissett Bullshit.
> I've never had any such statement in my CONFIG.SYS and VAC has always
> been fine. Why do you expect a compiler to use hundreds of threads
> anyway?
> You don't have to answer that one. I know you don't know the answer.
It is somewhere in the VAC308 docs, which I no longer have installed (and the line is inserted into CONFIG.SYS by the VAC308 installer). Chances are, that you never compiled anything that requires enough threads to kill the system (or, perhaps you did, and didn't recognize what the problem was).
Again, Paul makes a completely useless post, without first making sure
that he knows what he is talking about.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
>> 1) I assume that a higher value, which is already in my current
>> config.sys, would be acceptable.
>> 2) I have several config.sys files from other installations and most
>> use
>> THREADS=number
>> instead of
>> SET THREADS=number
>> Is the "SET" optional? (Does this mean than THREADS is a pseudo env.
>> variable?)
>> 3) Does this statement have to be in CONFIG.SYS to mean anything?
> Years ago, I remember looking at this. The details are a little fuzzy,
> but:
> SET THREADS=512 is something that VAC308 uses to contriol how many
> threads it will try to use. This needs to be "seen" by VAC308, when it
> runs, and it can be in a launch script, instead of in CONFIG.SYS.
> THREADS=1024 is something that OS/2 uses to control the number of
> threads that are available for all programs to use. This must be in
> CONFIG.SYS.
> I would assume, that VAC308 is trying to eliminate the possibility
> that it might use up all of the threads, leaving everything else in
> limbo.
It's a *compiler*, how the heck many threads *could* it use???
On Thu, 27 Sep 2012 20:37:13 +0200, A.D. Fundum <what.e...@neverm.ind> wrote:
> NHS: fail. Knowledge of installers: fail.
> > He know nothing
> > Something related to the Performance Analyzer IIRC.
> > I suspect
> > I would theink
> > such stuff
> > Presumably
> > No, it has to be just THREADS.
> I would think I suspect it's presumably something related to VAC3, > IIRC. Such stuff isn't just THREADS.
<dougb007!S...@telus.net> wrote:
>> > Years ago, I remember looking at this. The details are a little fuzzy,
>> > but:
>> > SET THREADS=512 is something that VAC308 uses to contriol how many >> > threads it will try to use. This needs to be "seen" by VAC308, when it
>> > runs, and it can be in a launch script, instead of in CONFIG.SYS.
>> I smell some more Bissett Bullshit.
>> I've never had any such statement in my CONFIG.SYS and VAC has always
>> been fine. Why do you expect a compiler to use hundreds of threads
>> anyway?
>> You don't have to answer that one. I know you don't know the answer.
> It is somewhere in the VAC308 docs, which I no longer have installed
Who believes the docs.? You can observe with your own eyes, if you
bothered to look, which of course you didn't.
> (and the line is inserted into CONFIG.SYS by the VAC308 installer).
Not by mine.
> Chances are, that you never compiled anything that requires enough > threads to kill the system (or, perhaps you did, and didn't recognize > what the problem was).
Chances are? WTF are you on about? XWP complicated enough for you?
Even that only executes at most two or three processes at once.
I repeat, what in a compiler do you expect to use hundreds of threads?
Can you PLEASE answer that question?
> Again, Paul makes a completely useless post, without first making sure
> that he knows what he is talking about.
Er, Douggy boy, is it you who makes useless posts, not me. You have
clearly proved on many occasions YOU don't know what YOU are talking
about.
0. Wtf cares?
1. His filter is broken, again.
2. NLOL. He's wrong, again (*, **)... :-(
3. He's trying to change the subjects, again.
4. It's a mystery, but all of my machines with an installed VAC 3.0x have SET THREADS=512 in x:\CONFIG.SYS. Strange.
5. He fails to admit that lines 5298 upto and including 5304 of the file VACPP.PKG (a.o. root directory of the CD) learn that SET THREADS=512 are added to a CONFIG.*-file by VAC's installer
6. He fails to admit that lines 5298 upto and including 5304 of the file VACPP.PKG (a.o. root directory of the CD) learn that SET THREADS=512 isn't THREAD=512, his own original, irrelevant story.
7. NURSE! He's out of bed again.
8. Get well soon.
*: regarding the 3.0 installer; not the 3.08 installer, albeit he failed to mention that. **: in rare cases it's possible to not let the installer update the CONFIG.SYS and to not update it manually, albeit he failed to mention such a rather unusual install procedure.
IOW: in a typical situation the installer processes VACPP.PKG, which causes a line reading SET THREADS=512 to be added to CONFIG.SYS. The line is also added to CSETENV.CMD. With a REM in front of it, because it should already be defined in CONFIG.SYS. I'll try to care less, but
maybe "systems programmers" (I am impressed!) received another install
CD and a package which never could need this SETting.
On Thu, 27 Sep 2012 12:42:05 UTC, "John Small" <jsm...@os2world.net> wrote:
> > Update CONFIG.SYS with the following, replacing E:\Development\IBMCPP > > with the correct path. (Watch out for extraneous line breaks in this > > post.)
> 1) This is for VACPP 3.08, correct?
Yes.
> 2) I was thinking of putting as little as possible in CONFIG.SYS and > putting all the others into a CMD file I would run when I am about to > use VACPP. The DEVICE statement, if used, clearly would need to be in > CONFIG.SYS. And I suspect that the THREADS statement, if used, would > also need to be in CONFIG.SYS. If I change the LIBPATH to SET > BEGINLIBPATH, how many of the other statements could be put in a CMD > file instead of CONFIG.SYS?
The SET THREADS statement (whatever it does) is an environment variable so it might be fine to put it in a CMD file. Don't confuse it with the THREADS=xxx (no SET) kernel directive, which does belong in CONFIG.SYS, but I see no reason for you to mess with that.
> > DEVICE=E:\Development\IBMCPP\SYS\CPPOPA3.SYS
> 1) What is this for? I did not have such a statement in my previous > CONFIG.SYS.
I don't recall but I gather from my own experience that it's not necessary to compile stuff, at least.
> 2) If I use this statement. does it mean I must include all the other > statements in CONFIG.SYS, too (so that the driver can find things)?
Can't answer that, I'm afraid.
I don't know all the ins and outs of what this all does, just that
these are what the VACPP installer put in my CONFIG.SYS - so I kept
them.
> > SET CPPHELP_INI=C:\OS2\SYSTEM
> Is there a reason this has to be a system directory? Could it point > somewhere else?
I'm sure you can put it wherever you like, but most things put their
INIs either in \OS2 or in the same location as OS2.INI (if different).
IMO it makes sense to keep them in one place.
> > SET THREADS=512
> 1) I assume that a higher value, which is already in my current > config.sys, would be acceptable.
> 2) I have several config.sys files from other installations and most use
> THREADS=number
> instead of > SET THREADS=number
> Is the "SET" optional? (Does this mean than THREADS is a pseudo env. > variable?)
Again, they are evidently not the same thing; I assume "SET THREADS"
means something to programs that look for it, but may not have any significance to the OS itself.
> 3) Does this statement have to be in CONFIG.SYS to mean anything?
> >> > Years ago, I remember looking at this. The details are a little fuzzy,
> >> > but:
> >> > SET THREADS=512 is something that VAC308 uses to contriol how many > >> > threads it will try to use. This needs to be "seen" by VAC308, when it
> >> > runs, and it can be in a launch script, instead of in CONFIG.SYS.
> >> I smell some more Bissett Bullshit.
> >> I've never had any such statement in my CONFIG.SYS and VAC has always
> >> been fine. Why do you expect a compiler to use hundreds of threads
> >> anyway?
> >> You don't have to answer that one. I know you don't know the answer.
> > It is somewhere in the VAC308 docs, which I no longer have installed
> Who believes the docs.? You can observe with your own eyes, if you
> bothered to look, which of course you didn't.
????? Now there is an intelligent statement...
> > (and the line is inserted into CONFIG.SYS by the VAC308 installer).
> Not by mine.
So, you didn't install the package using the defaults. Why am I not surprised?
> > Chances are, that you never compiled anything that requires enough > > threads to kill the system (or, perhaps you did, and didn't recognize > > what the problem was).
> Chances are? WTF are you on about? XWP complicated enough for you?
> Even that only executes at most two or three processes at once.
> I repeat, what in a compiler do you expect to use hundreds of threads?
> Can you PLEASE answer that question?
How would I know? Perhaps the OS/2 development team had a problem when
they were building Warp4, and did something about it.
> > Again, Paul makes a completely useless post, without first making sure
> > that he knows what he is talking about.
> Er, Douggy boy, is it you who makes useless posts, not me. You have
> clearly proved on many occasions YOU don't know what YOU are talking
> about.
You requested to be notified when you make useless posts. Consider yourself notified.
I did say that the details were somewhat fuzzy, but the basic idea is that "SET THREADS=512" means something to VACPP (probably an upper limit to the number of threads that it will try to use - why? I don't know, nor do I care). "THREADS=1024" is an instruction to the kernel to govern the number of threads that are available. YOU challenged that, as being incorrect, but have not presented anything to clarify the situation. All you did was argue that SET THREADS=512 was not installed in your CONFIG.SYS, so it isn't necessary. It probably isn't
in almost all cases, but it obviously means something to VACPP, and somebody needed it for something, or it wouldn't exist at all. My main
purpose in setting forth that argument was to point out that "SET THREADS=512" is something quite different to "THREADS=1024". I think I
did that the first time, and you disagreed. YOU are WRONG. Not me.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
On Fri, 28 Sep 2012 03:20:35 +0200, A.D. Fundum <what.e...@neverm.ind> wrote:
> 0. Wtf cares?
Not me. You're just a fucking wittering incompetent idiot.
> IOW: in a typical situation the installer processes VACPP.PKG, which > causes a line reading SET THREADS=512 to be added to CONFIG.SYS.
Yes but what does it achieve? I bet you cannot tell the difference with
it in or out.
Who's to say, in the general confusion about whether a "SET " is needed
on the front of it or not, that the geniuses at IBM Toronto where the
C compiler was developed didn't get all confused too and mis-wrote
the package file.
Stranger things have happened. It just makes no sense to add such a line.
You think they're God and can't get it wrong. I'm telling you they're not
and they can (and did).
<ab...@orac12.clara34.co56.uk78> wrote:
> On Fri, 28 Sep 2012 03:20:35 +0200, A.D. Fundum <what.e...@neverm.ind> wrote:
> > 0. Wtf cares?
> Not me. You're just a fucking wittering incompetent idiot.
Now that is an intelligent statement. Look in the mirror when you say things like that.
> > IOW: in a typical situation the installer processes VACPP.PKG, which > > causes a line reading SET THREADS=512 to be added to CONFIG.SYS.
> Yes but what does it achieve? I bet you cannot tell the difference with
> it in or out.
> Who's to say, in the general confusion about whether a "SET " is needed
> on the front of it or not, that the geniuses at IBM Toronto where the
> C compiler was developed didn't get all confused too and mis-wrote
> the package file.
Well, if the VACPP package actually does something with the entry, it should be included, and yes, it does require the "SET", because that is the way that it was implemented. This thread started with confusion
about "SET THREADS=" and "THREADS=" They are NOT the same, and each has it's own use, whether you believe it, or not. Even if the statement is not correct, it is prudent to include it, simply because there is an outside chance that it will be needed. If it is not needed, it obviously will do no harm.
> Stranger things have happened. It just makes no sense to add such a line.
Why not? You, obviously, have no idea what it is needed for. That doesn't mean that it doesn't make sense, it just means that you don't know what it is used for. There is nothing "strange" about it. Somebody needed whatever it happens to do, so it exists, and it was deemed important enough to make it a default setting in the installer.
> You think they're God and can't get it wrong. I'm telling you they're not
> and they can (and did).
No they didn't. It obviously does what it is supposed to do (or, it does nothing). Just because you don't happen to have run into the problem that it fixes, doesn't mean that others don't need it.
You, obviously, don't know what they did, or why. That doesn't make it
wrong, it just makes you claim to know something, that you obviously don't know. There is no doubt that mistakes were made, but every program ever written has bugs in it. Even your programs have bugs.
By the way, aren't you the one who is calling down Lars because he criticised somebody else's work? Pot, Kettle, Black.
> Now run along and don't bother me again.
Hmmm. Seems to me that YOU are the one who is doing the bothering. Now, run along, and quit bothering those who are trying to be helpful.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
On Fri, 28 Sep 2012 17:52:29 +0000 (UTC), Doug Bissett
<dougb007!S...@telus.net> wrote:
>> Yes but what does it achieve? I bet you cannot tell the difference with
>> it in or out.
>> Who's to say, in the general confusion about whether a "SET " is needed
>> on the front of it or not, that the geniuses at IBM Toronto where the
>> C compiler was developed didn't get all confused too and mis-wrote
>> the package file.
> Well, if the VACPP package actually does something with the entry, it > should be included, and yes, it does require the "SET", because that > is the way that it was implemented. This thread started with confusion
> about "SET THREADS=" and "THREADS=" They are NOT the same, and each > has it's own use, whether you believe it, or not.
I don't believe "SET THREADS=" has any use. That's the whole point of
the argument, which YET AGAIN you have missed the point about.
> Even if the > statement is not correct, it is prudent to include it, simply because > there is an outside chance that it will be needed. If it is not > needed, it obviously will do no harm.
If it doesn't do any good, what's the point in keeping it?
If just gives fools like you excuses to trot out arguments like this
one for ever and a day.
You still haven't given any indication of what all these hundreds
of potential threads are doing.
Is it because (shock horror) you don't know?
>> Stranger things have happened. It just makes no sense to add such a line.
> Why not? You, obviously, have no idea what it is needed for. That > doesn't mean that it doesn't make sense, it just means that you don't > know what it is used for. There is nothing "strange" about it. > Somebody needed whatever it happens to do, so it exists, and it was > deemed important enough to make it a default setting in the installer.
You just can't ever accept anything might be wrong can you?
>> You think they're God and can't get it wrong. I'm telling you they're not
>> and they can (and did).
> No they didn't.
How the hell do you know?
> It obviously does what it is supposed to do (or, it > does nothing). Just because you don't happen to have run into the > problem that it fixes, doesn't mean that others don't need it.
You don't need much intelligence to work out that it does nothing.
You haven't worked it out. That tells us your intelligence level.
> You, obviously, don't know what they did, or why. That doesn't make it
> wrong, it just makes you claim to know something, that you obviously > don't know.
Well you're the bleedin' expert on that, aren't you?
Do you want me to include <sarcasm> tags with that, or can you work it
out for yourself?
> By the way, aren't you the one who is calling down Lars because he > criticised somebody else's work? Pot, Kettle, Black.
I didn't criticise Lars. All I did was point out one small factual
inaccuracy, and you come wading in with both feet.
> Now, run along, and quit bothering those who are trying to be helpful.
The whole point is that you are not helpful by spreading misinformation.
On Fri, 28 Sep 2012 05:21:54 +0000 (UTC), Doug Bissett
<dougb007!S...@telus.net> wrote:
>> > It is somewhere in the VAC308 docs, which I no longer have installed
>> Who believes the docs.? You can observe with your own eyes, if you
>> bothered to look, which of course you didn't.
> ????? Now there is an intelligent statement...
I know. Obviously over your head.
>> > (and the line is inserted into CONFIG.SYS by the VAC308 installer).
>> Not by mine.
> So, you didn't install the package using the defaults.
I have no idea now. I was countless years ago.
> Why am I not surprised?
Defaults are there to be changed, if they make no sense.
You seem to be implying this is a BAD thing. It is a GOOD thing.
You would stick with a bad setting, come hell or high water, just
because someone else told you to.
"Doug, go jump in the river would you?" "Sure."
>> > Chances are, that you never compiled anything that requires enough >> > threads to kill the system (or, perhaps you did, and didn't recognize >> > what the problem was).
>> Chances are? WTF are you on about? XWP complicated enough for you?
>> Even that only executes at most two or three processes at once.
>> I repeat, what in a compiler do you expect to use hundreds of threads?
>> Can you PLEASE answer that question?
> How would I know?
So WHY are you arguing from a position of NO knowledge then?
You accuse me of same elsewhere but do it yourself.
You're just an ignorant hypocrite.
> Perhaps the OS/2 development team had a problem when
> they were building Warp4, and did something about it.
Perhaps they just fucked up a setting, like many other people have?
>> > Again, Paul makes a completely useless post, without first making sure
>> > that he knows what he is talking about.
>> Er, Douggy boy, is it you who makes useless posts, not me. You have
>> clearly proved on many occasions YOU don't know what YOU are talking
>> about.
> You requested to be notified when you make useless posts. Consider > yourself notified.
It's not a useless post. The balance of probabilities is way in my
favour, and way against yours.
> I did say that the details were somewhat fuzzy, but the basic idea is > that "SET THREADS=512" means something to VACPP (probably an upper > limit to the number of threads that it will try to use - why? I don't > know, nor do I care).
You seem to care enough to have pointless arguments about it.
> "THREADS=1024" is an instruction to the kernel > to govern the number of threads that are available.
That's the first thing you've got right this week.
> YOU challenged that, as being incorrect,
NO I DID NOT. WHERE EXACTLY DID I SAY ANY SUCH THING?
> but have not presented anything to clarify the situation.
Obviously, because I never said it. You have misinterpreted something.
> All you did was argue that SET THREADS=512 was not > installed in your CONFIG.SYS, so it isn't necessary.
I made a statement (not an argument) that it wasn't installed and that
I had never seen any ill effects from it not being there.
Then you come back with some other crap which we won't go over again.
> It probably isn't
> in almost all cases, but it obviously means something to VACPP,
Nobody can think of what it might be used for. Compilers just don't
have any need for such a thing. Just believe it for once.
> My main
> purpose in setting forth that argument was to point out that "SET > THREADS=512" is something quite different to "THREADS=1024". I think I
> did that the first time, and you disagreed. YOU are WRONG. Not me.
> >> > It is somewhere in the VAC308 docs, which I no longer have installed
> >> Who believes the docs.? You can observe with your own eyes, if you
> >> bothered to look, which of course you didn't.
> > ????? Now there is an intelligent statement...
> I know. Obviously over your head.
Obviously...
> >> > (and the line is inserted into CONFIG.SYS by the VAC308 installer).
> >> Not by mine.
> > So, you didn't install the package using the defaults.
> I have no idea now. I was countless years ago.
> > Why am I not surprised?
> Defaults are there to be changed, if they make no sense.
> You seem to be implying this is a BAD thing. It is a GOOD thing.
> You would stick with a bad setting, come hell or high water, just
> because someone else told you to.
> "Doug, go jump in the river would you?" "Sure."
If I was on a burning boat, sure I would.
You obviously know exactly what "SET THREADS=" does, and have decide that it is not applicable to your requirements, so tell us what it really does, since I obviously have no idea. Or, perhaps, you just got
lucky, and never needed it.
> >> > Chances are, that you never compiled anything that requires enough > >> > threads to kill the system (or, perhaps you did, and didn't recognize > >> > what the problem was).
> >> Chances are? WTF are you on about? XWP complicated enough for you?
> >> Even that only executes at most two or three processes at once.
> >> I repeat, what in a compiler do you expect to use hundreds of threads?
> >> Can you PLEASE answer that question?
> > How would I know?
> So WHY are you arguing from a position of NO knowledge then?
It seems to me that you are too.
> You accuse me of same elsewhere but do it yourself.
> You're just an ignorant hypocrite.
Look in the mirror when you say that.
> > Perhaps the OS/2 development team had a problem when
> > they were building Warp4, and did something about it.
> Perhaps they just fucked up a setting, like many other people have?
Perhaps you just never bothered to find out what the setting does?
> >> > Again, Paul makes a completely useless post, without first making sure
> >> > that he knows what he is talking about.
> >> Er, Douggy boy, is it you who makes useless posts, not me. You have
> >> clearly proved on many occasions YOU don't know what YOU are talking
> >> about.
> > You requested to be notified when you make useless posts. Consider > > yourself notified.
> It's not a useless post. The balance of probabilities is way in my
> favour, and way against yours.
The balance of probabilities has nothing to do with it. Look up "SET THREADS=" and tell us what it says. Apparently you still have the docs
installed. I don't, but I did look it up, years ago. As I said, the details are a bit fuzzy.
> > I did say that the details were somewhat fuzzy, but the basic idea is > > that "SET THREADS=512" means something to VACPP (probably an upper > > limit to the number of threads that it will try to use - why? I don't > > know, nor do I care).
> You seem to care enough to have pointless arguments about it.
You are the one who is arguing that "SET THREADS=" is something that the developers screwed up. Is it? Why? How do you know?
> > "THREADS=1024" is an instruction to the kernel > > to govern the number of threads that are available.
> That's the first thing you've got right this week.
> > YOU challenged that, as being incorrect,
> NO I DID NOT. WHERE EXACTLY DID I SAY ANY SUCH THING?
You edited what I said. Go back and READ what I posted.
> > but have not presented anything to clarify the situation.
> Obviously, because I never said it. You have misinterpreted something.
> > All you did was argue that SET THREADS=512 was not > > installed in your CONFIG.SYS, so it isn't necessary.
> I made a statement (not an argument) that it wasn't installed and that
> I had never seen any ill effects from it not being there.
> Then you come back with some other crap which we won't go over again.
> > It probably isn't
> > in almost all cases, but it obviously means something to VACPP,
> Nobody can think of what it might be used for. Compilers just don't
> have any need for such a thing. Just believe it for once.
Why would I believe it, when the developers of VACPP didn't believe it?
> > My main
> > purpose in setting forth that argument was to point out that "SET > > THREADS=512" is something quite different to "THREADS=1024". I think I
> > did that the first time, and you disagreed. YOU are WRONG. Not me.
> I think you have your wires crossed.
I think you don't listen very well. The parameter exists. It is good for something (even if YOU don't believe that), and it is considered important enough, by the developers, to include the statement in the default install. Since you don't seem to actually know what it is used
for, I think you should not be telling others that it is not necessary. You just don't know that.
-- From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
