Eiffel/Zlib Wrapping

5 Messages

Hubert Cater

Reply Threaded

Hello,

I experimented a bit with the Zlib today, essentially trying to adapt
the previous work done for the ELJ library by Uwe Sander for Eiffel
Studio.

I managed to get everything to compile Ok but when running the Example
application the program crashes on a 'c_external'. Wrapping C routines
is not my strength and I suspect the 'external' line, i.e. "C use
%"zlib.h%"" is not correct but cannot say for sure.

Here is the external routine where the program fails with an 'Operating
System Signal: Segmentation Violation'. Note all the arguments passed
are not Void so I don't think it is an argument issue.

c_deflate_init (a_stream: POINTER; a_level: INTEGER; a_version: POINTER;
a_struct_size: INTEGER): INTEGER is
-- (export status {NONE})
external
"C use %"zlib.h%""
alias
"deflateInit"
end

Below is the corresponding excerpt from the Zlib.h file:

/* deflateInit and inflateInit are macros to allow checking the zlib version
* and the compiler's view of z_stream:
*/
ZEXTERN int ZEXPORT deflateInit_ OF((z_streamp strm, int level,
const char *version, int
stream_size));
ZEXTERN int ZEXPORT inflateInit_ OF((z_streamp strm,
const char *version, int
stream_size));
ZEXTERN int ZEXPORT deflateInit2_ OF((z_streamp strm, int level, int
method,
int windowBits, int memLevel,
int strategy, const char *version,
int stream_size));
ZEXTERN int ZEXPORT inflateInit2_ OF((z_streamp strm, int windowBits,
const char *version, int
stream_size));
ZEXTERN int ZEXPORT inflateBackInit_ OF((z_streamp strm, int windowBits,
unsigned char FAR *window,
const char *version,
int stream_size));
#define deflateInit(strm, level) \
deflateInit_((strm), (level), ZLIB_VERSION,
sizeof(z_stream))
#define inflateInit(strm) \
inflateInit_((strm), ZLIB_VERSION,
sizeof(z_stream))
#define deflateInit2(strm, level, method, windowBits, memLevel, strategy) \
deflateInit2_((strm),(level),(method),(windowBits),(memLevel),\
(strategy), ZLIB_VERSION,
sizeof(z_stream))
#define inflateInit2(strm, windowBits) \
inflateInit2_((strm), (windowBits), ZLIB_VERSION,
sizeof(z_stream))
#define inflateBackInit(strm, windowBits, window) \
inflateBackInit_((strm), (windowBits), (window), \
ZLIB_VERSION, sizeof(z_stream))

Thanks in advance,
Hubert

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

rfo

RE: Eiffel/Zlib Wrapping

Reply Threaded

Hello Hubert!

Have you solved your problem yet? I haven't seen any other posts.
I had a quick look at the code you included in your email.

The
alias
"deflateInit"

in the Eiffel code clearly tells the Eiffel compiler to call deflateInit
with the arguments you've given to your external.

Things start to go wrong in the C code with:

#define deflateInit(strm, level) deflateInit_((strm), (level),
ZLIB_VERSION, sizeof(z_stream))

This macro expects 2 arguments, yet you are providing 4. It seems, from
the signature of your external, that you intended to call deflateInit_
the function, and not deflateInit the macro.
It might be interesting to have a look at the generated C code, and even
more interesting to see the result of it passing through the
preprocessor (-E flag) to see how mismatched macro/arglist even
compiled.

I know it's not a solution, but at least it's a response :)

R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: [eiffel_software] Eiffel/Zlib Wrapping
> From: Hubert Cater <hcater@...>
> Date: Fri, August 29, 2008 8:49 pm
> To: eiffel_software@...
> Hello,
> I experimented a bit with the Zlib today, essentially trying to adapt
> the previous work done for the ELJ library by Uwe Sander for Eiffel
> Studio.
> I managed to get everything to compile Ok but when running the Example
> application the program crashes on a 'c_external'. Wrapping C routines
> is not my strength and I suspect the 'external' line, i.e. "C use
> %"zlib.h%"" is not correct but cannot say for sure.
> Here is the external routine where the program fails with an 'Operating
> System Signal: Segmentation Violation'. Note all the arguments passed
> are not Void so I don't think it is an argument issue.
> c_deflate_init (a_stream: POINTER; a_level: INTEGER; a_version: POINTER;
> a_struct_size: INTEGER): INTEGER is
> -- (export status {NONE})
> external
> "C use %"zlib.h%""
> alias
> "deflateInit"
> end
> Below is the corresponding excerpt from the Zlib.h file:
> /* deflateInit and inflateInit are macros to allow checking the zlib version
> * and the compiler's view of z_stream:
> */
> ZEXTERN int ZEXPORT deflateInit_ OF((z_streamp strm, int level,
> const char *version, int
> stream_size));
> ZEXTERN int ZEXPORT inflateInit_ OF((z_streamp strm,
> const char *version, int
> stream_size));
> ZEXTERN int ZEXPORT deflateInit2_ OF((z_streamp strm, int level, int
> method,
> int windowBits, int memLevel,
> int strategy, const char *version,
> int stream_size));
> ZEXTERN int ZEXPORT inflateInit2_ OF((z_streamp strm, int windowBits,
> const char *version, int
> stream_size));
> ZEXTERN int ZEXPORT inflateBackInit_ OF((z_streamp strm, int windowBits,
> unsigned char FAR *window,
> const char *version,
> int stream_size));
> #define deflateInit(strm, level) \
> deflateInit_((strm), (level), ZLIB_VERSION,
> sizeof(z_stream))
> #define inflateInit(strm) \
> inflateInit_((strm), ZLIB_VERSION,
> sizeof(z_stream))
> #define deflateInit2(strm, level, method, windowBits, memLevel, strategy) \
> deflateInit2_((strm),(level),(method),(windowBits),(memLevel),\
> (strategy), ZLIB_VERSION,
> sizeof(z_stream))
> #define inflateInit2(strm, windowBits) \
> inflateInit2_((strm), (windowBits), ZLIB_VERSION,
> sizeof(z_stream))
> #define inflateBackInit(strm, windowBits, window) \
> inflateBackInit_((strm), (windowBits), (window), \
> ZLIB_VERSION, sizeof(z_stream))
> Thanks in advance,
> Hubert
> --
> Fury Software
> http://www.furysoftware.com
> Battlefront.com
> http://www.battlefront.com

Hubert Cater

Re: Eiffel/Zlib Wrapping

Reply Threaded

Hi Roger!

Thanks for your response and as suggested I tried to change the call to
deflateInit_ as well as to change to the call to appropriately call
deflateInit with only two arguments to no avail.

Embarrassingly I actually have little experience with C and I am not
even sure where to begin looking for the correct generated C code file
in the EIFGEN working directory as I have little experience with this
backend of the Eiffel system :(.

When I get some more time I will give it another try as well as to try
using the -E flag as suggested so thanks for these tips.

In the meantime if anyone is interested in what I have so far I would be
happy to send you the files. I believe I have a full wrapping of the
latest Zlib release into Eiffel, and while I do get a successful
compilation, as mentioned I am stuck on this Operating System Signal error.

For reference though I did have success with the EiffelCOM wizard in
wrapping an older Zlib OCX file that can now be used to compress file
data within Eiffel. The OCX file contains a real straightforward set of
features for the Zlib library, i.e. input file name/output file name as
well as single compress/decompress commands, i.e. no
initialization/streaming required, and it works brilliantly.

I also managed a roundabout way to compress Eiffel objects in memory by
loading the compressed file data into a RAW_FILE and then sending this
information through an established network connection from one computer
to another. Reduces my game saved files considerably in memory and as a
result increases the transmission speed for those that are on a slower
connection. The Zlib OCX file can be found here if anyone is interested
in that as well:

http://www.dogma.net/markn/ZlibOCX2.dll

Hubert

rfo@... wrote:

>
>
> Hello Hubert!
>
> Have you solved your problem yet? I haven't seen any other posts.
> I had a quick look at the code you included in your email.
>
> The
> alias
> "deflateInit"
>
> in the Eiffel code clearly tells the Eiffel compiler to call deflateInit
> with the arguments you've given to your external.
>
> Things start to go wrong in the C code with:
>
> #define deflateInit(strm, level) deflateInit_((strm), (level),
> ZLIB_VERSION, sizeof(z_stream))
>
> This macro expects 2 arguments, yet you are providing 4. It seems, from
> the signature of your external, that you intended to call deflateInit_
> the function, and not deflateInit the macro.
> It might be interesting to have a look at the generated C code, and even
> more interesting to see the result of it passing through the
> preprocessor (-E flag) to see how mismatched macro/arglist even
> compiled.
>
> I know it's not a solution, but at least it's a response :)
>
> R

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

rfo

RE: Eiffel/Zlib Wrapping

Reply Threaded

In reply to this post by Hubert Cater

Hello Hubert!

Would you mind sending the Eiffel code (and values, from the debugger or
even a printf) that you are giving the external?
Does the zlib documentation say anything about an initializing call that
has to precede other calls? It's common in crypto stuff, so I was
wondering if the compression lib might have such a case.
Have you tried the same call in the same circumstance with a simple C
program? If so, how are the values different?

R

==================================================
Roger F. Osmond
----------------------------------------
Amalasoft Corporation
273 Harwood Avenue
Littleton, MA 01460

> -------- Original Message --------
> Subject: Re: [eiffel_software] Eiffel/Zlib Wrapping
> From: Hubert Cater <hcater@...>
> Date: Mon, September 01, 2008 9:56 pm
> To: eiffel_software@...
> Hi Roger!
> Thanks for your response and as suggested I tried to change the call to
> deflateInit_ as well as to change to the call to appropriately call
> deflateInit with only two arguments to no avail.
> Embarrassingly I actually have little experience with C and I am not
> even sure where to begin looking for the correct generated C code file
> in the EIFGEN working directory as I have little experience with this
> backend of the Eiffel system :(.
> When I get some more time I will give it another try as well as to try
> using the -E flag as suggested so thanks for these tips.
> In the meantime if anyone is interested in what I have so far I would be
> happy to send you the files. I believe I have a full wrapping of the
> latest Zlib release into Eiffel, and while I do get a successful
> compilation, as mentioned I am stuck on this Operating System Signal error.
> For reference though I did have success with the EiffelCOM wizard in
> wrapping an older Zlib OCX file that can now be used to compress file
> data within Eiffel. The OCX file contains a real straightforward set of
> features for the Zlib library, i.e. input file name/output file name as
> well as single compress/decompress commands, i.e. no
> initialization/streaming required, and it works brilliantly.
> I also managed a roundabout way to compress Eiffel objects in memory by
> loading the compressed file data into a RAW_FILE and then sending this
> information through an established network connection from one computer
> to another. Reduces my game saved files considerably in memory and as a
> result increases the transmission speed for those that are on a slower
> connection. The Zlib OCX file can be found here if anyone is interested
> in that as well:
> http://www.dogma.net/markn/ZlibOCX2.dll
> Hubert
> rfo@... wrote:
> >
> >
> > Hello Hubert!
> >
> > Have you solved your problem yet? I haven't seen any other posts.
> > I had a quick look at the code you included in your email.
> >
> > The
> > alias
> > "deflateInit"
> >
> > in the Eiffel code clearly tells the Eiffel compiler to call deflateInit
> > with the arguments you've given to your external.
> >
> > Things start to go wrong in the C code with:
> >
> > #define deflateInit(strm, level) deflateInit_((strm), (level),
> > ZLIB_VERSION, sizeof(z_stream))
> >
> > This macro expects 2 arguments, yet you are providing 4. It seems, from
> > the signature of your external, that you intended to call deflateInit_
> > the function, and not deflateInit the macro.
> > It might be interesting to have a look at the generated C code, and even
> > more interesting to see the result of it passing through the
> > preprocessor (-E flag) to see how mismatched macro/arglist even
> > compiled.
> >
> > I know it's not a solution, but at least it's a response :)
> >
> > R
> --
> Fury Software
> http://www.furysoftware.com
> Battlefront.com
> http://www.battlefront.com

Hubert Cater

Re: Eiffel/Zlib Wrapping

Reply Threaded

Roger I will send you the files I put together and hopefully you can see
the obvious error that I seem to be overlooking. Thanks again.

For the Zlib documentation, you are correct and essentially the first
call needs to be a call to deflatInit before any compression or calls to
deflate() are made.

As I mentioned before the example I put together as well as the
libraries were more or less ports of the work Uwe Sander did for the ELJ
project which had a few of its own classes and designed to work for
either Small Eiffel or ISE. I essentially removed any Small Eiffel and
ELJ library references and put it together using only EiffelStudio
classes as well as a few from GOBO that I didn't easily find
replacements for.

His example appeared to follow the Zlib Usage Example documentation on
the Zlib home pages and from his notes it was apparently successful.
One thing I did notice was that he rebuilt the Zlib.lib file as well as
rewrote a customized version of the zlib.h file so I suspect the
disconnect with my version and his version is somewhere in these two
files. I tried to use his files but they were built with lcc and I am
currently using the MSC compiler so it was a no go.

Anyways I will send you the files shortly,
Hubert

rfo@... wrote:

>
>
> Hello Hubert!
>
> Would you mind sending the Eiffel code (and values, from the debugger or
> even a printf) that you are giving the external?
> Does the zlib documentation say anything about an initializing call that
> has to precede other calls? It's common in crypto stuff, so I was
> wondering if the compression lib might have such a case.
> Have you tried the same call in the same circumstance with a simple C
> program? If so, how are the values different?
>
> R
>
> ==================================================
> Roger F. Osmond
> ----------------------------------------
> Amalasoft Corporation
> 273 Harwood Avenue
> Littleton, MA 01460
>
> > -------- Original Message --------
> > Subject: Re: [eiffel_software] Eiffel/Zlib Wrapping
> > From: Hubert Cater <hcater@...
> <mailto:hcater%40furysoftware.com>>
> > Date: Mon, September 01, 2008 9:56 pm
> > To: eiffel_software@...
> <mailto:eiffel_software%40yahoogroups.com>
> > Hi Roger!
> > Thanks for your response and as suggested I tried to change the call to
> > deflateInit_ as well as to change to the call to appropriately call
> > deflateInit with only two arguments to no avail.
> > Embarrassingly I actually have little experience with C and I am not
> > even sure where to begin looking for the correct generated C code file
> > in the EIFGEN working directory as I have little experience with this
> > backend of the Eiffel system :(.
> > When I get some more time I will give it another try as well as to try
> > using the -E flag as suggested so thanks for these tips.
> > In the meantime if anyone is interested in what I have so far I would be
> > happy to send you the files. I believe I have a full wrapping of the
> > latest Zlib release into Eiffel, and while I do get a successful
> > compilation, as mentioned I am stuck on this Operating System Signal
> error.
> > For reference though I did have success with the EiffelCOM wizard in
> > wrapping an older Zlib OCX file that can now be used to compress file
> > data within Eiffel. The OCX file contains a real straightforward set of
> > features for the Zlib library, i.e. input file name/output file name as
> > well as single compress/decompress commands, i.e. no
> > initialization/streaming required, and it works brilliantly.
> > I also managed a roundabout way to compress Eiffel objects in memory by
> > loading the compressed file data into a RAW_FILE and then sending this
> > information through an established network connection from one computer
> > to another. Reduces my game saved files considerably in memory and as a
> > result increases the transmission speed for those that are on a slower
> > connection. The Zlib OCX file can be found here if anyone is interested
> > in that as well:
> > http://www.dogma.net/markn/ZlibOCX2.dll
> <http://www.dogma.net/markn/ZlibOCX2.dll>
> > Hubert
> > rfo@... <mailto:rfo%40amalasoft.com> wrote:
> > >
> > >
> > > Hello Hubert!
> > >
> > > Have you solved your problem yet? I haven't seen any other posts.
> > > I had a quick look at the code you included in your email.
> > >
> > > The
> > > alias
> > > "deflateInit"
> > >
> > > in the Eiffel code clearly tells the Eiffel compiler to call
> deflateInit
> > > with the arguments you've given to your external.
> > >
> > > Things start to go wrong in the C code with:
> > >
> > > #define deflateInit(strm, level) deflateInit_((strm), (level),
> > > ZLIB_VERSION, sizeof(z_stream))
> > >
> > > This macro expects 2 arguments, yet you are providing 4. It seems, from
> > > the signature of your external, that you intended to call deflateInit_
> > > the function, and not deflateInit the macro.
> > > It might be interesting to have a look at the generated C code, and
> even
> > > more interesting to see the result of it passing through the
> > > preprocessor (-E flag) to see how mismatched macro/arglist even
> > > compiled.
> > >
> > > I know it's not a solution, but at least it's a response :)
> > >
> > > R
> > --
> > Fury Software
> > http://www.furysoftware.com <http://www.furysoftware.com>
> > Battlefront.com
> > http://www.battlefront.com <http://www.battlefront.com>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.169 / Virus Database: 270.6.14/1647 - Release Date: 9/2/2008 6:02 AM
>

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com