gmane.comp.lang.eiffel.ise

Re: Re: Return a STRING from C external

Fernando Pelliccioni — 2013-06-19T02:56:45


Maybe this can help ...

http://stackoverflow.com/questions/6288759/why-could-glgetstringgl-version-be-causing-a-seg-fault

Regards,
Fernando.


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



------------------------------------

refactor cmd

2013-06-19T01:31:42

Hi All

I just made a disturbing discovery and I'm more than a little miffed.
I was busily renaming a few classes using the rename option in the
refactor tool menu.
Worked fine until I tried renaming a class that was "not in the system".
Rather than telling me I had no business renaming it (cuz nobody uses
it), it went ahead and renamed it alright, and it modified EVERY file in
EVERY cluster that my program used.  Clearly there is an inverted flag
somewhere, and this is pretty horrid behavior.  Every file on the planet
(pretty much) has had at least its time stamp changed FOR NO REASON.  It
destroyed whatever information I might have gathered from relative
timestamps.

R

==================================================
Roger F. Osmond


------------------------------------

EDITABLE_TEXT_PANEL

Karsten — 2013-06-18T09:25:34

Dear Manu,

thank you very much for the F4 hint.
All asssertion checks were False for EDITABLE_TEXT_PANEL,
whereas MY_EDITABLE_TEXT_PANEL checked all of them.
This explains the difference.

Unicode text (at least cyrillic and CJK characters)
cannot be moved properly in EDITABLE_TEXT_PANEL.
The misbehavior occurs if selected text is moved with the mouse
as well as with copy/paste or cut/paste.

I will post a problem report at http://support.eiffel.com.

Regards,
Karsten



------------------------------------

Re: More Void-safety problems

Alexander Kogtenkov — 2013-06-18T09:17:38


If you have a reproducible example, post it to support.eiffel.com, please,
as this is definitely something to be fixed.

Thank you,
Alexander Kogtenkov


------------------------------------

Re: More Void-safety problems

Thomas Beale — 2013-06-18T09:08:23

I wiped the project and recompiled from scratch, and the compiler came 
up with a completely different VDRD error, relating to classes from 
different clusters, but not the 8 errors in the above group.

So according to the compiler, starting from scratch, the above 
ISO8601_DATE / DV_DATE 'error' does not really exist...

- thomas




------------------------------------

RE: More Void-safety problems

Emmanuel Stapf — 2013-06-17T13:39:57

Here in that case it is saying that you cannot redefine `out: attached STRING' coming from
ANY in a descendant class to be `out: detachable STRING'. So the class ISO8601_DATE would
have to be compiled with attached by default to get the proper signature `out: attached
STRING'. If you say that this is already the case, we would just need a backup of your
project and submit it to http://support.eiffel.com so that we can have a look.

Regards,
Manu




------------------------------------

RE: EDITABLE_TEXT_PANEL

Emmanuel Stapf — 2013-06-17T08:14:40

Actually this might be related to a project settings. Check the assertions level
associated with the class MY_EDITABLE_TEXT_PANEL. To do so, open the class and press F4,
you will see the properties panel appearing in the UI. It will tell you what are the
assertions being checked on your class.


This is to signal the compiler that once set it will never be Void again. It helps in the
writing of code by avoiding too many object tests to check that it is not Void.


EiffelStudio is using some descendants of the editor library classes with minor
modifications mostly related to code editing (formatting, indentation ...), completion and
pick and drop. Does copy/paste work properly? If you could send a problem report at
http://support.eiffel.com that would be great.

Thanks,
Manu



------------------------------------

RE: EV_MULTI_COLUMN_LIST - set_column_titles no longer working

Emmanuel Stapf — 2013-06-17T07:46:21

Thanks for the report. This should be fixed in the 7.3 release.

Manu



------------------------------------

EDITABLE_TEXT_PANEL

Karsten — 2013-06-15T17:06:37

Dear Manu,

thank you very much for your reply.
OK, the editor library can work with `cursors' being void.
But the question remains:
No precondition violation occurs
on left clicking in an EDITABLE_TEXT_PANEL
but it occurs with MY_EDITABLE_TEXT_PANEL:

class MY_EDITABLE_TEXT_PANEL
inherit EDITABLE_TEXT_PANEL
end

Why? Is 'option: stable' involved here?

--

In an EDITABLE_TEXT_PANEL it is possible
to move selected text with the mouse.
Unfortunately, unicode text disappears
if moved this way.
(I tried cyrillic and CJK text.)

This behavior cannot be replicated
in EiffelStudio's editor panel.
What classes are used for EiffelStudio's
editing capabilities?

Thanks again.

Regards,
Karsten



------------------------------------

Re: EV_MULTI_COLUMN_LIST - set_column_titles no longer working

Thomas Beale — 2013-06-14T16:23:26

Looks like I am right here.  I have reproduced this by modifying the 
ITEM_LIST_CONTROL test class in the examples/widgets area .... 
set_column_titles() is definitely no longer working.

I'll raise a bug report and provide the test code.

- thomas



------------------------------------

Re: Void-safety and parameterized ecf

Thomas Beale — 2013-06-14T12:07:56

Manu,

these things will probably make some aspects of converting easier. But 
the underlying problem remains, which is that there is heavy dependence 
in most people's libraries on the gobo libs, and it will take time for 
that to be upgraded.

I still think that some sort of declared 'void safe container' would be 
useful, to encapsulate libs that are technically (i.e. code level) not 
provable by the compiler to be void safe, but are known (i.e. already 
heavily tested) to be essentially trustworthy.

Otherwise it is going to be a long time before we can designate the void 
safety level of a system as a whole as any more than 'none' due to the 
lowest-level rule...

- thomas

On 11/06/2013 12:00, Emmanuel Stapf wrote:



------------------------------------

RE: Re: Return a STRING from C external

Emmanuel Stapf — 2013-06-14T04:25:08

If you can prepare a reproducible sample and send it to http://support.eiffel.com, that
will help in providing an answer.

Regards,
Manu 



------------------------------------

Re: Return a STRING from C external

Jimmy Johnson — 2013-06-14T02:31:26


--- In eiffel_software-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Emmanuel Stapf" <manus< at >...> wrote:

Great, thanks.  But my original posting gives a segmentation violation, so I must have missed something.  Any ideas what?





------------------------------------

RE: Re: Return a STRING from C external

Emmanuel Stapf — 2013-06-12T21:21:23

Yes, you could use `eif_string' as you did in your original post is a way to do that but I
personally prefer to return the POINTER and handle this better in Eiffel as often you do
not always get an ASCII string but something else that needs some special handling that
can be provided by either C_STRING, WEL_STRING or NATIVE_STRING.

Regards,
Manu



------------------------------------

RE: Void-safety and parameterized ecf

Emmanuel Stapf — 2013-06-11T11:00:02

Hi,

Having two ECFs is very unfortunate and is very specific to the way void-safety was
brought up to allow people to easily migrate their code to have code running side-by-side.
One has to understand that a library compiled in one mode is a library of its own. Thus
library LIB void-safe and library LIB non-void-safe are different. We thought at first
that it was a better that way so that people can actually try to migrate their code one
library at a time and it is very easy to track progress.

As possibly mentioned in some earlier messages, our goal is to change the void-safety
settings from one specific to a library to one specific to a project. Then it would be
very easy with one ECF per library to go back and forth between the void-safety levels.
The only drawback is that while waiting for all libraries to be fully void-safe the
project void-safety level would have to be set to the void-safety level of the library
with the lowest compatible level of void-safety. Not ideal but it will work for most
proje

Void-safety and parameterized ecf

olivier.ligot — 2013-06-10T12:52:42

Hi,

I just want to bring back a subject that has already been discussed here, namely Void-safety and parameterized ecf.

A small reminder: this subjet was introduced when discussing the migration path toward Void-safety:
http://tech.groups.yahoo.com/group/eiffel_software/message/20064
and also reopened when discussing the inclusion of Gobo ecf files:
http://tech.groups.yahoo.com/group/gobo-eiffel/message/1823

The basic idea is this: you are developing a library X that you are migrating toward Void-safety and you want the user of this library to have the choice between the Void-safe and the non Void-safe version of your library.
Currently, the "EiffelSofware" way to achieve this is to ship two different (but very similar) ecf files: 
* one with the Void-safety option enabled and possibly pointing to other Void-safe libraries
* the other with the Void-safety option disabled and possibly pointing to other non Void-safe libraries

According to Eric Bezault, we should instead have a single ecf file that can be

Re: Return a STRING from C external

Jimmy Johnson — 2013-06-08T01:04:43

Thanks Manu.

Is there no way to simply return a STRING, avoiding the use of POINTER and the additional Eiffel-side code?


--- In eiffel_software-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Emmanuel Stapf" <manus< at >...> wrote:





------------------------------------

RE: Return a STRING from C external

Emmanuel Stapf — 2013-06-07T21:23:47

The way I would do it is:

gl_get_string (name: INTEGER): POINTER
 external
 "C inline use <gl.h>"
 alias
 "return glGetString ((GLenum) $name);"
 end

And then from the Eiffel side:

ptr := gl_get_string (val)
if ptr /= default_pointer then
create str.make_from_c (ptr)
end


The version from Paul is actually using an alternative way to reference the C external by
just specifying the name and letting the compiler figuring out how to perform the call.
The C inline is more powerful as it let you do a lot more. In addition using square
brackets or curly braces is only relevant for formatting, it does not have an effect
otherwise.
 

Simply list all headers by separating them by a coma:

use <windows.h>, <stdio.h>

Regards,
Manu



------------------------------------

Return a STRING from C external

Jimmy Johnson — 2013-06-07T20:13:39

How do I wrap this OpenGL function to return a STRING?  This gives a segmentation violation.

glGetString (a_constant: INTEGER): STRING
     external
          "C inline use <gl.h>"
     alias
          "{
               char* s;
               s = glGetString ((GLenum)$a_constant);
               return (EIF_REFERENCE) eif_string (s);
          }"
     end


Paul Cohen's OpenGL library did it this way, but that gives a POINTER.

gl_get_string (name: INTEGER): POINTER
external
--"C (GLenum): GLubyte* | <gl.h>"
"C [macro <gl.h>] (GLenum): GLubyte*"
alias
"glGetString"
end

Can someone explain the meaning of the lines in the above code?  Why the quotes around glGetString instead of a "normal" looking C method call?

Why can I use square brackets instead of curly braces?  Is there a preferred method?

How do you handle a C external that may need to reference more than one C header?

thanks,
jjj



------------------------------------

EV_MULTI_COLUMN_LIST - set_column_titles no longer working

Thomas Beale — 2013-06-07T18:19:47

In all places where I use EV_MULTI_COLUMN_LIST.set_column_titles(), only 
the first column title appears. This is new, but I am not sure if it is 
an Eiffel 7.2 thing or something in a library of mine. I started 
debugging, but like all Vision2, very hard to follow the code.... anyone 
else seen this problem?

- thomas



------------------------------------