headers
rfo | 1 Sep 2008 03:31

RE: [eiffel_software] Eiffel/Zlib Wrapping

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

==================================================
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hubert Cater | 2 Sep 2008 03:56

Re: Eiffel/Zlib Wrapping

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Tafuri | 2 Sep 2008 13:11
Picon

Hello everybody!

Hi,

I´m Alan Tafuri, a solution developer residing in Brazil.

I´d like to say that I´m happy to find this group, and wish to share with
all of you my experiences with Eiffel products -though I´m still new to this
-, and with other subjects as well.

Best regards,
Alan.

[Non-text portions of this message have been removed]

------------------------------------
Permalink | Reply | 0 comments |
headers
rfo | 2 Sep 2008 13:36

RE: [eiffel_software] Eiffel/Zlib Wrapping

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hubert Cater | 2 Sep 2008 20:44

Re: Eiffel/Zlib Wrapping

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!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian King | 3 Sep 2008 19:05
Favicon

Re: Non-conforming inheritance bug?

Hi Jonathan,

Sorry for the late reply, your code is indeed valid but due to a bug in 
the way the 6.2 compiler handles replicated features with regards to 
non-conforming inheritance, an invalid VEEN error is generated.  This 
bug has now been fixed and should make it in to our 6.3 development 
branch soon.

Hope this helps

Ian King
Eiffel Software

Jonathan S. Ostroff wrote:
>
> I wondered if I am using non-conforming inheritance incorrectly? I get a
> VEEN error.
>
> Class ACCOUNT feature
> balance: INTEGER
> deposit(v: INTEGER)
> require v > 0
> do
> -- implementation.
> end
>
> feature{NONE}
> implementation: ACCOUNT_I
> end
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Helmut Brandl | 4 Sep 2008 02:00
Picon

Question to the use of "SPECIAL"

Is it possible in EiffelStudio / FreeELKS to inherit from SPECIAL?

Since SPECIAL is frozen, I asume that conformant inheritance is not 
allowed. But nonconformant inheritance shall be possible (at least 
according to the Eiffel standard).

The reason for asking this seemingly sophisticated question is to make 
tecomp as compatible as possible to FreeELKS/EiffelStudio. Since the 
standard does not give a clear answer, I thought I better ask reality 
than theory.

Regards
Helmut

The Eiffel Compiler: http://www.sourceforge.net/projects/tecomp
Documentation: http://tecomp.sourceforge.net

------------------------------------
Permalink | Reply | 1 comment |
headers
marvin_littlewood_426716 | 4 Sep 2008 02:37
Picon
Favicon

Re: Detection of feature availability changes

--- In eiffel_software@..., "Emmanuel Stapf [ES]" 
<manus <at> ...> wrote:
>
> > If you hide a feature by changing its availability, code outside the
> > class that calls it, still runs correctly until you compile clean. 
Is
> > this deliberate? For an example, consider the initial code for 
class A:
> 
> No this should not happen. Could you submit a problem report at
> http://support.eiffel.com?
> 
> Thanks,
> Manu
>

Dear Manu

Before I do...

I have found the precise circumstances where this occurs. It is when 
class A is in a not-precompiled library that is read-only in the 
project where class B resides.

Arguably the failure is reasonable behaviour - read-only libraries 
should be assumed to be complete and final before using them. 

However, I am writing test cases for a library in one project and the 
library code in another. I thought that adding the library in read-only 
mode would be a reasonable approach, in that it simulates my intended
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Bezault | 4 Sep 2008 08:33
Gravatar

Re: Question to the use of "SPECIAL"

Helmut Brandl wrote:
> Is it possible in EiffelStudio / FreeELKS to inherit from SPECIAL?
> 
> Since SPECIAL is frozen, I asume that conformant inheritance is not 
> allowed. But nonconformant inheritance shall be possible (at least 
> according to the Eiffel standard).
> 
> The reason for asking this seemingly sophisticated question is to make 
> tecomp as compatible as possible to FreeELKS/EiffelStudio. Since the 
> standard does not give a clear answer, I thought I better ask reality 
> than theory.

I shared the same point of view about theory. In fact in my opinion
SPECIAL should not be frozen. But as far as I know (Manu will need
to confirm) there is a implementation issue that prevents EiffelStudio
supporting inheritance from SPECIAL (even non-conforming). I hope
that this implementation issue will be addressed at some point.

--

-- 
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

------------------------------------
Permalink | Reply | 0 comments |
headers
azador1606 | 4 Sep 2008 09:48
Picon
Favicon

Eiffel for .NET - what exactly is the state of play?


Can someone elucidate the state of Eiffel .NET development?

My understanding from the documentation was that .NET 1.0 and 1.1 were
(somewhat) supported.

But there is anecdotal evidence that at least .NET 2.0 has been tried
to some degree.

This may "just work" for those with just .NET 1.1 installed on a
Windows box. That seems to me how is "should" happen (doesn't work AT
ALL for me). My understanding is that certain assemblies are
automatically "consumed" to provide access from Eiffel - essentially
by linking to them and providing peer Eiffel classes - and that other
assemblies can be added as well.

Is there anyone authoritative for Eiffel .NET development or is it
just left to chance? (not a criticism - it's completely normal for
open source projects to have very uneven coverage)

Does EiffelStudio emit MSIL code directly? or does it rely on the C
compiler to do so?

Has anyone attempted to build a .NET version of EiffelStudio itself?

[Don't get defensive, I understand the difficulties involved.
EiffelStudio is a huge product and very very good, I just want to
evaluate whether it is suitable for what I want to do (leave
wage-slave conditions and contract program with tools and processes of
my own choosing). - but my prospective clients (dictated by my network
(Continue reading)

Permalink | Reply | 4 comments |

Gmane