Discussion:
[CsMain] VFS Plugin temporary fix!
(too old to reply)
a***@wwwconsulting.com
2000-10-02 04:46:01 UTC
Permalink
Ok, I know this is a hack, I should have figured this out before when Torlach Rush told us that the assertion problem was in deleting the buffer variable. So what I did was REMOVE the damn delete [] buf; all throughout csparser.cpp.

Also in csWorld->Prepare() stop the precalc_info from being saved, that way you can avoid having to remove more buffer deletes down the road.

The silly memory heap assertion problem also occurs in Windows during the cleanup() function when it tries to delete cctest::Sys;. Commenting that out causes the apps to exit properly and quietly.

Which leads me to this question, do we really NEED to delete these variables? Aren't they technically supposed to get deleted automatically when the function loses scope? Or was it they just arent linked to that function and sit around in nomans land?

At least I got CCTest and WalkTest running now.

Adam Bailey
Torlach Rush
2000-10-02 07:55:12 UTC
Permalink
Memory allocated by malloc/calloc etc. is not released when functions lose
scope except when using smart pointers (an MS implememtation I believe, and
in fact these would still produce the debug assertion failures). I dont
think its a good idea to leave unwanted/unused memory lying around. Aside
from performance issues, doing so will eventually bring any system down.

Torlach

-----Original Message-----
From: ***@wwwconsulting.com [mailto:***@wwwconsulting.com]
Sent: Sunday, October 01, 2000 9:46 PM
To: crystal-***@lists.sourceforge.net
Subject: [CsMain] VFS Plugin temporary fix!



Ok, I know this is a hack, I should have figured
this out before when Torlach Rush told us that the assertion problem was in
deleting the buffer variable. So what I did was REMOVE the damn delete []
buf; all throughout csparser.cpp.

Also in csWorld->Prepare() stop the precalc_info from being saved, that way
you can avoid having to remove more buffer deletes down the road.

The silly memory heap assertion problem also occurs in Windows during the
cleanup() function when it tries to delete cctest::Sys;. Commenting that out
causes the apps to exit properly and quietly.

Which leads me to this question, do we really NEED to delete these
variables? Aren't they technically supposed to get deleted automatically
when the function loses scope? Or was it they just arent linked to that
function and sit around in nomans land?

At least I got CCTest and WalkTest running now.

Adam Bailey
Jorrit Tyberghein
2000-10-02 08:43:23 UTC
Permalink
Can someone explain to me why people like Thomas Hieber and Martin Geisse
seem able to develop on Windows just fine and why all those other people are
reporting problems?

Greetings,
Post by Torlach Rush
Memory allocated by malloc/calloc etc. is not released when functions lose
scope except when using smart pointers (an MS implememtation I believe, and
in fact these would still produce the debug assertion failures). I dont
think its a good idea to leave unwanted/unused memory lying around. Aside
from performance issues, doing so will eventually bring any system down.
--
==============================================================================
***@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

People who used magic without knowing what they were doing usually came to
a sticky end. All over the entire room, sometimes.
-- (Terry Pratchett, Moving Pictures)
==============================================================================
Thomas Hieber
2000-10-02 14:51:52 UTC
Permalink
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and Martin Geisse
seem able to develop on Windows just fine and why all those other people are
reporting problems?
I can only answer this for myself: I currently use a lazy update mechanism.
That means, I do update _very_ rarely and fix everything that needs to be
fixed then. This seems to be far more efficient that checking out day by
day. At least if your primary target is to get something new done.

Thomas
Andrew Zabolotny
2000-10-02 11:02:16 UTC
Permalink
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and Martin Geisse
seem able to develop on Windows just fine and why all those other people are
reporting problems?
There were indeed the two problems reported before, but maybe they did not
affect you. Problem number one is that since VFS has become a separate plugin
this could cause problems because ReadFile() for example returns a new array
which is supposed to be delete[]'d by caller (and we discussed before that this
is a Bad Thing to do since the plugins can be in a different address space).
The second problem was present as well (delete System) but as far as I see you
fixed it (I fixed it as well but in a different manner).

I'm going to commit now a large update which includes a fix for the first
problem.

Greetings,
_\***@teamOS/2
Andrew Zabolotny
2000-10-02 11:02:16 UTC
Permalink
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and Martin Geisse
seem able to develop on Windows just fine and why all those other people are
reporting problems?
There were indeed the two problems reported before, but maybe they did not
affect you. Problem number one is that since VFS has become a separate plugin
this could cause problems because ReadFile() for example returns a new array
which is supposed to be delete[]'d by caller (and we discussed before that this
is a Bad Thing to do since the plugins can be in a different address space).
The second problem was present as well (delete System) but as far as I see you
fixed it (I fixed it as well but in a different manner).

I'm going to commit now a large update which includes a fix for the first
problem.

Greetings,
_\***@teamOS/2
Torlach Rush
2000-10-02 16:33:29 UTC
Permalink
I concur with this. I on the other hand download daily and do a full clean
followed by
a full build of CS and the apps. I then test each and every app.
Thomas Hieber
2000-10-02 19:29:40 UTC
Permalink
Post by Torlach Rush
I concur with this. I on the other hand download daily and do a full clean
followed by
a full build of CS and the apps. I then test each and every app.
Thomas Hieber
2000-10-06 13:49:49 UTC
Permalink
Post by Torlach Rush
I concur with this. I on the other hand download daily and do a full clean
followed by
a full build of CS and the apps. I then test each and every app. From
what
Post by Torlach Rush
Thomas is saying
he may not even have the plugin version of VFS.
I have not run any CS application for more than a month now. I guess I
will
start doing this again, as soon as I have a version of the csgame plugin,
that I would expect to do something useful.
(Today I have committed a bunch of fixes, because I have done an update on
my second PC and wanted to test if I can set up and test two new project
files, one for the csgame camecore plugin and one for the csgame phython
plugin. Anyway, I only managed to get parts of the project compile again.
It
looks like Andrews changes did too much damage to the rest of the stuff.
At
least I can compile the csgame plugin now, so I can start implementing
some
of the interfaces.)
Please ignore the comments about my "Today" fixes. It was supposed to be
sent about a week ago. It must have been lost in my "Outgoing" folder.

Thomas
Thomas Hieber [mailto:]
1970-01-01 00:00:00 UTC
Permalink
Torlach

-----Original Message-----
From: Thomas Hieber [mailto:***@gmx.net]
Sent: Monday, October 02, 2000 7:52 AM
To: crystal-***@lists.sourceforge.net
Subject: Re: [CsMain] VFS Plugin temporary fix!
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and Martin Geisse
seem able to develop on Windows just fine and why all those other people
are
Post by Jorrit Tyberghein
reporting problems?
I can only answer this for myself: I currently use a lazy update mechanism.
That means, I do update _very_ rarely and fix everything that needs to be
fixed then. This seems to be far more efficient that checking out day by
day. At least if your primary target is to get something new done.

Thomas
Seth Galbraith
2000-10-02 16:28:36 UTC
Permalink
Post by Thomas Hieber
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and Martin Geisse
seem able to develop on Windows just fine and why all those other people
are reporting problems?
I can only answer this for myself: I currently use a lazy update mechanism.
That means, I do update _very_ rarely and fix everything that needs to be
day. At least if your primary target is to get something new done.
It isn't really fair to expect a few people to maintain the Windows ports
by themselves - doing all of the testing and keeping up with CVS updates.

It would probably help if more casual users would update frequently,
report bugs when they fix them, AND try to find ways to fix those bugs (or
if the bug is too complex to fix you can try to understand it better.)
Often those bugs are routine maintanence like updating project files for
MSVC++, perhaps that process can be documented so that anybody can do it.

I think the general health of an "open sores" project like this depends on
the efforts of many moderately competent, casually interested
user/tester/developers as much as it depends on the efforts of a few
heroic and dedicated designer/engineer/developers.
__ __ _ _ __ __
_/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_
\__/ \__/ \_ ***@krl.org #2244199 on ICQ _/ \__/ \__/
_/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_
FragDance Galore
2000-10-02 18:06:01 UTC
Permalink
Well, I've got WinCVS setup and CS updated from CVS, so I might be able to
at least keep the project files up to date soon.

FragDance
Post by Thomas Hieber [mailto:]
Subject: Re: [CsMain] VFS Plugin temporary fix!
Date: Mon, 2 Oct 2000 09:28:36 -0700 (PDT)
Post by Thomas Hieber
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and Martin
Geisse
Post by Thomas Hieber
Post by Jorrit Tyberghein
seem able to develop on Windows just fine and why all those other
people
Post by Thomas Hieber
Post by Jorrit Tyberghein
are reporting problems?
I can only answer this for myself: I currently use a lazy update
mechanism.
Post by Thomas Hieber
That means, I do update _very_ rarely and fix everything that needs to
be
Post by Thomas Hieber
day. At least if your primary target is to get something new done.
It isn't really fair to expect a few people to maintain the Windows ports
by themselves - doing all of the testing and keeping up with CVS updates.
It would probably help if more casual users would update frequently,
report bugs when they fix them, AND try to find ways to fix those bugs (or
if the bug is too complex to fix you can try to understand it better.)
Often those bugs are routine maintanence like updating project files for
MSVC++, perhaps that process can be documented so that anybody can do it.
I think the general health of an "open sores" project like this depends on
the efforts of many moderately competent, casually interested
user/tester/developers as much as it depends on the efforts of a few
heroic and dedicated designer/engineer/developers.
__ __ _ _ __ __
_/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_
_/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.
Paul Garceau
2000-10-03 00:01:07 UTC
Permalink
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and
Martin Geisse seem able to develop on Windows just fine and why
all those other people are reporting problems?
I can only attribute this to the development environment they
are working in and how they define their projects locally.
There is an offhand possibility that the later the msvc/c++
release the less it conforms to ansi standards.

Linux is an ansi-standard development system, unlike the MSVS
based development environments which rely on msvc/c++
compilers/linkers (idiosyncrasies, MS headers, MS macros) to
work.

MSVC/C++ is non-ansi standard, and if you force ansi-standard
compliance for msvc/c++ (this occurs in both the Borland/Inprise
based compilers AND the MSVS based compilers) by setting
switches which force strict-ansi , you can run into a great deal
of problems when working with msvc/c++ builds.
It is very subtle, in that some MSVC/C++ calls are very similar
syntactically to ansi-standard calls, but in fact are not ansi-
standard at all.

What this indicates is a conflict between the compilers being
used. Assuming that everyone is using the exact same hardware,
the exact same release of the MSVS version and the exact same
system configuration as Martin or Thomas, imho, is a mistake.

For instance, all of the gcc ports for Windows are, by their
nature, ansi-standard.

However, in order to get them to work with MS source code,
these ansi-standard compilers (mingw, cygwin) must mutate to
accomodate what is, basically, a non-ansi standard approach to
building CS in order to work with the Win32 API. (No, I am not
making a veiled comment about the positives and negatives of
developing with MSVC/C++).

In terms of CS Development, this means that there are a great
deal of pre-definitions assumed when it comes to msvc/c++
development. These "pre-definitions" have to do with the .dsp
and/or any other project oriented definitions (including the
differences between 'gnu-make' and 'nmake" requirements) that
are assumed for MSVC/C++ (both overt and subtle).

To put in another way, there is a specific mindset required for
MSVC/C++ development. One that really has nothing to do with
the mindset of the Linux C/C++ developers (or any Gnu-C/C++) in
terms of how something is assembled or put together, even the
the source code is, for all intents and purposes, "identical".
That is, it is designed to produce a specific product for a
specific OS.
The Linux source, is, in essence, the core source-code or "base-
line" of CS. Any variations that occur with regards to this
Linux/Gnu C/C++ baseline directly influence whatever variations
become necessary further down the road in order for the "core"
source-code to work with other operating systems.
As the variations to the Linux baseline increase, so too does
the liklihood that something that works quite nicely under a
Linux system will not work at all under something like a Windows
system. This latter (The Win32API source code), in turn, must
then be modifed or "mutated" sufficiently to maintain base-line
functionality comparable (in a very general sense) to the Linux
base-line functionality.

The binding "glue" for all this, at least for CS, is the core
source-code of CS. Beyond that, as graphics drivers, sound
drivers and network drivers are added, a phenomenon begins to
occur that is metaphorically similar to making multiple copies
of the same original document when using non-digital methods of
reproduction.
ie. The greater the amount of copies the less similar the final
copy looks when visually compared with the original copy. It
may also be seen as a "dilution" of the image, or in this case,
the source-code in question. This might also be considered
"software rot".

Software rot itself, or the "likliness of software rot
occurring" increases proportionally to the amount software being
handled and/or "bolted-on" to the baseline source-code as it is
defined for the Linux development environment. Here we are
referencing the interface between the non-Linux OS and the Linux
OS.

I am not referring to the CS API here. I am referring to what
happens on the other side of the CS API when the system on the
other side of the CS API (relative to the CS Core) is an
operating system developed by MS.

A very large piece of software (in terms of the amount of
source-code lines -- not binary images) will be more likely to
have instances of "rot" associated with it than something with a
smaller amount of source-code lines (eg. hellowin.cpp, hello.c
are "not vulnerable to software rot" by nature of their
simplicity).
If we then start adding plugins or "enhancements" to that core
collection of source-code (in this case, CS), we increase the
"liklihood" or "probability" that software rot will occur and
will manifest itself in the form of something like missing
drivers...not because the drivers aren't there or because they
aren't being built, but because of the way the source-code, for
lack of a better reference, dictates assumptions for those
drivers and how those drivers "must" be used and/or "loaded for
use".

The builds themselves are not a problem, they all compile and,
for the most part, link just fine. It is how the various facets
of the CS API and the Win32 API attempt to interact with each
other that seems to be at the root of the problems recently
appearing with CS "Fatal Errors", etc.

Anyway, that is my take on the situation.

Peace,

Paul G.
Post by Jorrit Tyberghein
Greetings,
Post by Torlach Rush
Memory allocated by malloc/calloc etc. is not released when
functions lose scope except when using smart pointers (an MS
implememtation I believe, and in fact these would still produce
the debug assertion failures). I dont think its a good idea to
leave unwanted/unused memory lying around. Aside from
performance issues, doing so will eventually bring any system
down.
--
=================================================================
Hospitals KU Leuven BELGIUM
People who used magic without knowing what they were doing
usually came to a sticky end. All over the entire room,
sometimes.
-- (Terry Pratchett, Moving Pictures)
=================================================================
=============
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
Nothing real can be threatened.
Nothing unreal exists.
Seth Galbraith
2000-10-07 20:00:08 UTC
Permalink
Think about the acronym GNU: "GNU's Not Unix" - see how it defines itself?
Likewise a GNU/Linux system can recompile itself. Even if you use
proprietary tools to develop for linux, those tools have to work in that
self-defined environment.

Unfortunately the Windows environment is not self-defining. It's defined
by seperate proprietary software. This leads to the heart of our problem:
There are many different Windows developer platforms. Even though the end
user has only a few options (95, 98, ME, NT or 2000) The developer has
all those platforms to test multiplied by the number of possible
compilers.

That's a major problem for an open source project, because every supported
development tool is a different platform. Also, when those development
tools are proprietary, each version can be a different platform, because
you can't tell every developer to buy the latest version of the tools, and
if your port maintainer has the latest version of the tools, he may not
be able to test how well his port works with older versions.

Using a Free, self-defining development environment is the closest you can
get to making a single, actually maintainable, Windows version of any open
source software. (Well, there is another option, only support one version
of one proprietary compiler, but that falls apart as soon as some
determined character starts a port to his own compiler/version)

Not only is the free development environment available to all developers,
but you can also often require users to upgrade to a newer or customized
version of a free tool, because the new version is also available to
everyone.

Crystal Space is not a little utility that can easily be recompiled on
many platforms. Instead it's a complex system in it's own right that is
extremely difficult to maintain on multiple platforms - especially
platforms that refuse to adhere to any standards.

If we were all employees in the same department of the same software
development company, the idea that we were all using different compiler
setups to develop a complex library like CS for the same target would be
simply laughable.

So should we continue to use this laughable approach just because we don't
have a manager telling us to "get our act together"?

I don't think we should. I think the most important thing is putting
together a windows port that any windows user can build for themselves,
regardless of what proprietary tool versions they own.

Now I do understand that there are good reasons why we have been bending
over backward to have ports of CS to many different proprietary
development environments and versions. But those reasons have a lot to do
with the way things _have_been_ and that strategy is completely
ineffective for the way things _need_to_be_.

The various ports have allowed more people to work on CS, and more people
to try out the end-products, but eventually many of those ports will fall
apart, and few of them have ever been as up to date as the various
non-Windows GCC ports.

Waiting for someone to come along and update those old ports is just a way
of saying "we accept that one attempt at a windows port failed to endure,
maybe it will work out next time." I don't think it will work out.
Rather than accepting failures, we should try to turn them into
opportunities to make our project better.

One idea along those lines is to stop using MSVC project files and use the
same makefile system for all platforms. At first this seems silly. First
of all it's a superficial solution to a deeper problem. and second, why
use a command line tool when you have a nice IDE like MSVC?

But on the other hand, how many windows developers are "lagged" in their
ability to use and contribute to the latest version of Crystal Space
because they wait for the MSVC project files to be updated? Many
people will just abandon the project when they can't get it to work with
the project files we distribute with CS. Other people will lose interest
as they get tired of the "lag time".

It is easy to download and use GNU Make and other GNU utilities. Even if
this strikes some MSVC users as "strange" or "inconvenient", learning the
makefile system is a one-time cost for a solution to a long-term problem.

This message is getting a bit longer than I planned :-)

Any replies are welcomed.
Post by Paul Garceau
Post by Jorrit Tyberghein
Can someone explain to me why people like Thomas Hieber and
Martin Geisse seem able to develop on Windows just fine and why
all those other people are reporting problems?
I can only attribute this to the development environment they
are working in and how they define their projects locally.
There is an offhand possibility that the later the msvc/c++
release the less it conforms to ansi standards.
Linux is an ansi-standard development system, unlike the MSVS
based development environments which rely on msvc/c++
compilers/linkers (idiosyncrasies, MS headers, MS macros) to
work.
MSVC/C++ is non-ansi standard, and if you force ansi-standard
compliance for msvc/c++ (this occurs in both the Borland/Inprise
based compilers AND the MSVS based compilers) by setting
switches which force strict-ansi , you can run into a great deal
of problems when working with msvc/c++ builds.
It is very subtle, in that some MSVC/C++ calls are very similar
syntactically to ansi-standard calls, but in fact are not ansi-
standard at all.
What this indicates is a conflict between the compilers being
used. Assuming that everyone is using the exact same hardware,
the exact same release of the MSVS version and the exact same
system configuration as Martin or Thomas, imho, is a mistake.
For instance, all of the gcc ports for Windows are, by their
nature, ansi-standard.
However, in order to get them to work with MS source code,
these ansi-standard compilers (mingw, cygwin) must mutate to
accomodate what is, basically, a non-ansi standard approach to
building CS in order to work with the Win32 API. (No, I am not
making a veiled comment about the positives and negatives of
developing with MSVC/C++).
In terms of CS Development, this means that there are a great
deal of pre-definitions assumed when it comes to msvc/c++
development. These "pre-definitions" have to do with the .dsp
and/or any other project oriented definitions (including the
differences between 'gnu-make' and 'nmake" requirements) that
are assumed for MSVC/C++ (both overt and subtle).
To put in another way, there is a specific mindset required for
MSVC/C++ development. One that really has nothing to do with
the mindset of the Linux C/C++ developers (or any Gnu-C/C++) in
terms of how something is assembled or put together, even the
the source code is, for all intents and purposes, "identical".
That is, it is designed to produce a specific product for a
specific OS.
The Linux source, is, in essence, the core source-code or "base-
line" of CS. Any variations that occur with regards to this
Linux/Gnu C/C++ baseline directly influence whatever variations
become necessary further down the road in order for the "core"
source-code to work with other operating systems.
As the variations to the Linux baseline increase, so too does
the liklihood that something that works quite nicely under a
Linux system will not work at all under something like a Windows
system. This latter (The Win32API source code), in turn, must
then be modifed or "mutated" sufficiently to maintain base-line
functionality comparable (in a very general sense) to the Linux
base-line functionality.
The binding "glue" for all this, at least for CS, is the core
source-code of CS. Beyond that, as graphics drivers, sound
drivers and network drivers are added, a phenomenon begins to
occur that is metaphorically similar to making multiple copies
of the same original document when using non-digital methods of
reproduction.
ie. The greater the amount of copies the less similar the final
copy looks when visually compared with the original copy. It
may also be seen as a "dilution" of the image, or in this case,
the source-code in question. This might also be considered
"software rot".
Software rot itself, or the "likliness of software rot
occurring" increases proportionally to the amount software being
handled and/or "bolted-on" to the baseline source-code as it is
defined for the Linux development environment. Here we are
referencing the interface between the non-Linux OS and the Linux
OS.
I am not referring to the CS API here. I am referring to what
happens on the other side of the CS API when the system on the
other side of the CS API (relative to the CS Core) is an
operating system developed by MS.
A very large piece of software (in terms of the amount of
source-code lines -- not binary images) will be more likely to
have instances of "rot" associated with it than something with a
smaller amount of source-code lines (eg. hellowin.cpp, hello.c
are "not vulnerable to software rot" by nature of their
simplicity).
If we then start adding plugins or "enhancements" to that core
collection of source-code (in this case, CS), we increase the
"liklihood" or "probability" that software rot will occur and
will manifest itself in the form of something like missing
drivers...not because the drivers aren't there or because they
aren't being built, but because of the way the source-code, for
lack of a better reference, dictates assumptions for those
drivers and how those drivers "must" be used and/or "loaded for
use".
The builds themselves are not a problem, they all compile and,
for the most part, link just fine. It is how the various facets
of the CS API and the Win32 API attempt to interact with each
other that seems to be at the root of the problems recently
appearing with CS "Fatal Errors", etc.
Anyway, that is my take on the situation.
Peace,
Paul G.
Post by Jorrit Tyberghein
Greetings,
Post by Torlach Rush
Memory allocated by malloc/calloc etc. is not released when
functions lose scope except when using smart pointers (an MS
implememtation I believe, and in fact these would still produce
the debug assertion failures). I dont think its a good idea to
leave unwanted/unused memory lying around. Aside from
performance issues, doing so will eventually bring any system
down.
--
=================================================================
Hospitals KU Leuven BELGIUM
People who used magic without knowing what they were doing
usually came to a sticky end. All over the entire room,
sometimes.
-- (Terry Pratchett, Moving Pictures)
=================================================================
=============
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
Nothing real can be threatened.
Nothing unreal exists.
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main
__ __ _ _ __ __
_/ \__/ \__/ Seth Galbraith "The Serpent Lord" \__/ \__/ \_
\__/ \__/ \_ ***@krl.org #2244199 on ICQ _/ \__/ \__/
_/ \__/ \__/ http://www.planetquake.com/gg \__/ \__/ \_
Continue reading on narkive:
Loading...