<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.eiffel.ise">
    <title>gmane.comp.lang.eiffel.ise</title>
    <link>http://blog.gmane.org/gmane.comp.lang.eiffel.ise</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11030"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11029"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11025"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11024"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11022"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11021"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11017"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11016"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10993"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10989"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10984"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10982"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10976"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10975"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10973"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10963"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10954"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10953"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10952"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10951"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11030">
    <title>Eiffel Selenium Binding</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11030</link>
    <description>&lt;pre&gt;Hi all,

Just to let you know, I added a new EWF library under /library/test/selenium
This library will help to write automated web test, using Selenium with Eiffel- 
For now the library is under my git account, you can find it here https://github.com/jvelilla/EWF/tree/master/library/test/selenium
Note, the library is still under development.

Here a simple example of use
 class
    EXAMPLE_SEARCH
    
    inherit
    
    ANY
    redefine
    default_create
    end
    
    feature
    
    default_create
    do
    search
    end
    
    feature -- Example
    
    search
    local
    web_driver: WEB_DRIVER
    wait: WEB_DRIVER_WAIT
    do
    --Create a new instance of a Web driver
    create web_driver.make
    
    -- Start session with chrome
    web_driver.start_session_chrome
    
    -- Go to Google
    web_driver.to_url ("http://www.google.com/")
    
    -- Find the text input element by its name
    if attached web_driver.find_element ((create {SE_BY}).name ("q")) as l_element then
    
    -- Enter something to search for
    l_element.send_keys (&amp;lt;&amp;lt;"Eiffel Room"&amp;gt;&amp;gt;)
    
    -- Now submit the form. WebDriver will find the form for us from the element
    l_element.submit
    end
    if attached web_driver.get_page_tile as l_title then
    print ("%NPage title is:" + l_title)
    end
    
    -- Google's search is rendered dynamically with JavaScript.
    -- Wait for the page to load, timeout after 10 seconds
    create wait.make (web_driver, 10)
    wait.until_when (agent expected_title(web_driver, "Eiffel Room"))
    if attached web_driver.get_page_tile as l_title then
    print ("%NPage title is:" + l_title)
    end
    
    -- close the window
    web_driver.window_close
    end
    
    expected_title (driver: WEB_DRIVER; title: STRING_32): BOOLEAN
    do
    if attached {STRING_32} driver.get_page_tile as l_title and then l_title.has_substring (title) then
    Result := True
    end
    end
    end

You can find more examples here https://github.com/jvelilla/EWF/tree/master/library/test/selenium/examples

Any comments, improvements or suggestions are welcome. 

Thanks
/Javier



Thanks



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

&lt;/pre&gt;</description>
    <dc:creator>javier</dc:creator>
    <dc:date>2013-05-23T10:58:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11029">
    <title>Setting background color per tab in a EV_NOTEBOOK</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11029</link>
    <description>&lt;pre&gt;Is it possible to set the background color for a specific tab in an EV_NOTEBOOK?



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

&lt;/pre&gt;</description>
    <dc:creator>colin_paul_adams</dc:creator>
    <dc:date>2013-05-15T14:26:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11025">
    <title>Include cocoa cluster in project</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11025</link>
    <description>&lt;pre&gt;I am trying to create a project that uses the cocoa library, but I keep getting the GTK clusters.  What must I do to make this work?  Thanks

jjj



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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-05-14T03:26:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11024">
    <title>two classes with same name</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11024</link>
    <description>&lt;pre&gt;How do I resolve a name conflict when classes from two clusters have the same name?  (I've searched for past messages but cannot find it.)

jjj



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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-05-14T03:10:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11022">
    <title>[Catcall Solution]Default and explicit variance</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11022</link>
    <description>&lt;pre&gt;I published a new proposal for catcall resolution.

The proposal is inspired of other solutions
http://dev.eiffel.com/Default_and_explicit_variance

If you identify english faults don't hesitate to change this.
Thanks.



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

&lt;/pre&gt;</description>
    <dc:creator>Victorien ELVINGER</dc:creator>
    <dc:date>2013-05-10T09:40:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11021">
    <title>More WEL_RBBS_CONSTANTS</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11021</link>
    <description>&lt;pre&gt;While trying to use a WEL_REBAR, I found that several of windows' RBBS_... constants are absent from the WEL_RBBS_CONSTANTS class, even though some of the constants are useful. Here is what's missing:

Rbbs_gripperalways: INTEGER
external
"C [macro %"cctrl.h%"]"
alias
"RBBS_GRIPPERALWAYS"
end

Rbbs_nogripper: INTEGER
external
"C [macro %"cctrl.h%"]"
alias
"RBBS_NOGRIPPER"
end

Rbbs_usechevron: INTEGER
external
"C [macro %"cctrl.h%"]"
alias
"RBBS_USECHEVRON"
end

Rbbs_variableheight: INTEGER
external
"C [macro %"cctrl.h%"]"
alias
"RBBS_VARIABLEHEIGHT"
end

Rbbs_hidetitle: INTEGER
external
"C [macro %"cctrl.h%"]"
alias
"RBBS_HIDETITLE"
end

Rbbs_topalign: INTEGER
external
"C [macro %"cctrl.h%"]"
alias
"RBBS_TOPALIGN"
end

Maybe they can be included in the future?

Best,
Mischa





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

&lt;/pre&gt;</description>
    <dc:creator>mischa.megens</dc:creator>
    <dc:date>2013-05-10T04:22:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11017">
    <title>How to prevent Buttons from changing size?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11017</link>
    <description>&lt;pre&gt;Hi

I would like several buttons to remain a fixed size in a horizontal box how is this achieved in EiffelBuild?

Thanks



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

&lt;/pre&gt;</description>
    <dc:creator>kardpoll</dc:creator>
    <dc:date>2013-05-09T18:54:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11016">
    <title>Notebook Control</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/11016</link>
    <description>&lt;pre&gt;Is it possible to turn off the tabs in a notebook control so that the only way to select tabs is via code?

Thanks,
Simon



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

&lt;/pre&gt;</description>
    <dc:creator>kardpoll</dc:creator>
    <dc:date>2013-05-09T18:40:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10993">
    <title>Using keyword 'old'</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10993</link>
    <description>&lt;pre&gt;Whilst debugging using EiffelStudio, I  discovered that 'old count' is being mapped to value#1, and if there are multiples of 'old' &amp;lt;fields&amp;gt; then each gets a respective value #n assigned to it.

If there are multiples of 'old' being used then one could by inference determine what is what - however is there a better way to actually map a given value #n to the actual variable (perhaps the entity could be displayed as o-count)?

Any advice on techniques you use to make sense of value#n would be most welcome.

thanks,

Sushil.

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



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

&lt;/pre&gt;</description>
    <dc:creator>sushil shelly</dc:creator>
    <dc:date>2013-05-02T18:24:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10989">
    <title>SYSTEM_STRING_FACTORY in EiffelStudio 7.2</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10989</link>
    <description>&lt;pre&gt;Hi Manu,

In Eiffel .NET projects, SYSTEM_STRING_FACTORY is responsible for converting back and forth between .NET String objects (which are UTF-16) and Eiffel strings (STRING_8, STRING_32, etc.).

SYSTEM_STRING_FACTORY was heavily rewritten in EiffelStudio 7.2:

https://svn.eiffel.com/wsvn/revision.php?repname=eiffelstudio&amp;amp;path=%2Ftrunk%2FSrc%2Flibrary%2Fbase%2Fise%2Fkernel%2Fdotnet%2F&amp;amp;rev=90063&amp;amp;peg=90063

https://svn.eiffel.com/wsvn/diff.php?repname=eiffelstudio&amp;amp;path=%2Ftrunk%2FSrc%2Flibrary%2Fbase%2Fise%2Fkernel%2Fdotnet%2Fsystem_string_factory.e&amp;amp;rev=90063&amp;amp;peg=90063

The changes seem to have been to support manipulating Unicode file paths in .NET:

http://dev.eiffel.com/EiffelStudio_7.2_Releases

I get the impression that the the main concern was to improve support for STRING_32 Unicode conversions, but reading the code it seems to me that it ought to work just as well for STRING_8 (i.e., UTF-8). But when I run it with our Visual Basic .NET application, Unicode characters (apart from normal ASCII) are displayed as garbage. It's the same problem that the old implementation of SYSTEM_STRING_FACTORY had. For example, this text in Arabic:

قد تكون التخصيصات أكثر مناسبة للتقارير المركبة مثل حالات الميكروبيولوجيا أو الهيستوباثولوجيا

... displays like this in the .NET application:

ÙØ¯ ØªÙÙÙ Ø§ÙØªØ®ØµÙØµØ§Øª Ø£ÙØ«Ø± ÙÙØ§Ø³Ø¨Ø© ÙÙØªÙØ§Ø±ÙØ± Ø§ÙÙØ±ÙØ¨Ø© ÙØ«Ù Ø­Ø§ÙØ§Øª Ø§ÙÙÙÙØ±ÙØ¨ÙÙÙÙØ¬ÙØ§ Ø£Ù Ø§ÙÙÙØ³ØªÙØ¨Ø§Ø«ÙÙÙØ¬ÙØ§

Or, to take a simpler example, the copyright symbol "©" displays as "Â©".

I'm not 100% certain at this stage that SYSTEM_STRING_FACTORY is to blame, but it certainly looks that way. So, in order to get conversions between STRING_8 and .NET Strings to work properly, it seems that I still need to use the fix that I described many years ago:

http://www.eiffelroom.com/blog/peter_gummer/utf_8_in_net_revisited

Before I go to the effort of trying to adapt my old solution to the new SYSTEM_STRING_FACTORY implementation, however, could you clarify why these changes were made to the class in EiffelStudio 7.2? Maybe I've misinterpreted your intentions. In particular, I'm confused as to why the conversions from STRING_8 to .NET Strings aren't working.

- Peter Gummer


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

&lt;/pre&gt;</description>
    <dc:creator>Peter Gummer</dc:creator>
    <dc:date>2013-05-02T13:18:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10984">
    <title>outputting to stderr</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10984</link>
    <description>&lt;pre&gt;
most command line Eiffel programs send feedback to the console with 
either io.put_string () or print (). I need to control this properly to 
be output =&amp;gt; stdout and error output to std_err. It appears that the 
only way to do this is to use the STD_FILES modal set_error_default and 
set_output_default calls.

That means if you have some code that wants to do (logical pseudo-code):

...
stdout.put_string ("xxxxx")
...
stderr.put_string ("err err err")
...
stdout.put_string ("xxxxx")


you actually have to do:

...
io.put_string ("xxxx")
...
io.set_error _default
io.put_string ("err err err")
io.set_output_default
...
io.put_string ("xxxxx")


and you only get away with that if you trust that no developer forgot to 
switch the default output back to standard out after reporting an error.

I have never really thought about it before, but this hardly makes 
sense. Why doesn't ANY just have the following?

stderr: PLAIN_TEXT_FILE
stdout: PLAIN_TEXT FILE

Or am I missing something basic  here?

- thomas



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

&lt;/pre&gt;</description>
    <dc:creator>Thomas Beale</dc:creator>
    <dc:date>2013-05-01T15:47:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10982">
    <title>C2Eif LibmongoDB: MinGW gcc compile error</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10982</link>
    <description>&lt;pre&gt;I switched my ISE_C_COMPILER --&amp;gt; mingw (from msc) in order to get the library to compile as it has some external dependencies on the MinGW.

Questions:

1. What can we do to also get msc support rather than just mingw?
2. If option #1 is not doable, then what can I do about the following error:

"C:\Program Files (x86)\Eiffel Software\EiffelStudio 7.2 Enterprise/gcc/windows/mingw/bin/gcc"  -mconsole -o libmongo_demo.exe E1/emain.o  libmongo_demo.res E2/Eobj2.o E1/eparents.o  E1/einit.o  E1/ececil.o  E1/evisib.o  E1/enames.o  E1/eskelet.o  E1/eplug.o  E1/esize.o  E1/epoly.o  E1/eref.o  C19/Cobj19.o C18/Cobj18.o C17/Cobj17.o C16/Cobj16.o C15/Cobj15.o C14/Cobj14.o C13/Cobj13.o C12/Cobj12.o C11/Cobj11.o C10/Cobj10.o C9/Cobj9.o C8/Cobj8.o C7/Cobj7.o C6/Cobj6.o C5/Cobj5.o C4/Cobj4.o C3/Cobj3.o C2/Cobj2.o C1/Cobj1.o   "C:\Program Files (x86)\Eiffel Software\EiffelStudio 7.2 Enterprise/studio/spec/windows/lib/mingw/finalized.a" -luser32 -lws2_32 -ladvapi32 -lgdi32 -lshell32 -lmsimg32 -lcomdlg32 -luuid -lole32 -loleaut32 -lcomctl32 -lmpr -lshlwapi -lwinspool -lstdc++ 
C4/Cobj4.o:big_file_C4_c.c:(.text+0x52): undefined reference to `ffi_type_longdouble'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x72): undefined reference to `ffi_type_pointer'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xa2): undefined reference to `ffi_type_void'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xb2): undefined reference to `ffi_type_sint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xc2): undefined reference to `ffi_type_sint16'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd2): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xe2): undefined reference to `ffi_type_sint64'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xf2): undefined reference to `ffi_type_uint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x102): undefined reference to `ffi_type_uint16'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x112): undefined reference to `ffi_type_uint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x122): undefined reference to `ffi_type_uint64'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x132): undefined reference to `ffi_type_float'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x142): undefined reference to `ffi_type_double'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x152): undefined reference to `ffi_type_pointer'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x489a): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd278): undefined reference to `ffi_type_double'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd318): undefined reference to `ffi_type_float'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd3b8): undefined reference to `ffi_type_uint64'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd458): undefined reference to `ffi_type_uint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd4f8): undefined reference to `ffi_type_uint16'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd598): undefined reference to `ffi_type_uint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd638): undefined reference to `ffi_type_sint64'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd6d8): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd778): undefined reference to `ffi_type_sint16'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd818): undefined reference to `ffi_type_sint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd8b8): undefined reference to `ffi_type_uint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd942): undefined reference to `ffi_prep_cif'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xd963): undefined reference to `ffi_call'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xdcde): undefined reference to `ffi_type_pointer'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xdd91): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xe363): undefined reference to `ffi_type_longdouble'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xf22f): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0xf3ef): undefined reference to `ffi_type_void'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x1105b): undefined reference to `ffi_closure_alloc'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x1108c): undefined reference to `ffi_prep_cif'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x110c4): undefined reference to `ffi_prep_raw_closure_loc'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x11267): undefined reference to `ffi_type_sint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x11394): undefined reference to `ffi_type_sint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x113b3): undefined reference to `ffi_type_sint16'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x113d2): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x113f1): undefined reference to `ffi_type_sint64'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x11410): undefined reference to `ffi_type_uint8'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x1142f): undefined reference to `ffi_type_uint16'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x1144e): undefined reference to `ffi_type_uint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x1146d): undefined reference to `ffi_type_uint64'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x1148c): undefined reference to `ffi_type_float'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x114ae): undefined reference to `ffi_type_double'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x115e8): undefined reference to `ffi_type_sint32'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x11670): undefined reference to `ffi_type_void'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x116fe): undefined reference to `ffi_type_pointer'
C4/Cobj4.o:big_file_C4_c.c:(.text+0x11982): undefined reference to `ffi_type_pointer'
collect2: ld returned 1 exit status
make.exe": *** [libmongo_demo.exe] Error 1




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

&lt;/pre&gt;</description>
    <dc:creator>larry_rix</dc:creator>
    <dc:date>2013-04-30T19:37:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10976">
    <title>Class MEMORY</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10976</link>
    <description>&lt;pre&gt;Hi

A feature in the MEMORY class is set_max_mem. As a parameter it has a INTEGER_32. 
Which is the default value? 
Maximum value?
Why not INTGEGER_64?

Regards

Anders



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

&lt;/pre&gt;</description>
    <dc:creator>andersoxie</dc:creator>
    <dc:date>2013-04-26T16:43:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10975">
    <title>jjj  Limit the movement of an EV_MOVE_HANDLE</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10975</link>
    <description>&lt;pre&gt;I have an EV_MODEL inside an EV_MOVE_HANDLE.  The handle is inside anther EV_MODEL which is an irregular shaped polygon.  I want to prevent the handle from leaving the polygon.  In other words, if the mouse is dragged beyond the edge of the polygon, leave focus with the handle but freeze the handle at that point until the mouse comes back into the polygon.

Here are my assumptions:
1)  To keep focus with the handle:
            handle.start_actions.extend (agent handle.enable_capture)
            handle.end_actions.extend (agent handle.disable_capture)

2)  I can determine when part of my object leaves the enclosing polygon.

How do I freeze the handle (with the encased model) at the point the encased model is about to leave the polygon?

How do I get the handle back under the mouse when the pointer is dragged back into the window?

thanks.



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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-04-25T18:59:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10973">
    <title>not is_empty</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10973</link>
    <description>&lt;pre&gt;We are constantly writing the following code:

 

not my_string.is_empty

 

We would rather write something like:

 

my_string.is_not_empty OR

my_string.not_is_empty OR

my_string.is_empty.not

 

What would be a little strange, but something to consider is:

 

my_string.is_empty not

 

Where the negation follows along after the positive condition seeing as
how this is apparently how the human brain wants to serve it up (in our
case that is)

 

The key realization is: No matter how long we all do this, the human
tendency is to write the positive condition first and negate it
afterward. Writing a natural sentence, we always say, "Is not empty" and
we never say, "Not is empty". Based on this, the proper answer seems to
be my_string.is_not_empty.

 

It's the little annoyances that drive one crazy.

 

 

Larry

 



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



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

&lt;/pre&gt;</description>
    <dc:creator>Rix, Larry</dc:creator>
    <dc:date>2013-04-24T17:57:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10963">
    <title>EiffelBuild</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10963</link>
    <description>&lt;pre&gt;Why di get that exception?

esbuilder: PANIC: Unexpected harmful signal (Segmentation violation) ...

esbuilder: system execution failed.
Following is the set of recorded exceptions.
NB: The raised panic may have induced completely inconsistent information:

-------------------------------------------------------------------------------
Class / Object      Routine                Nature of exception
Effect
-------------------------------------------------------------------------------
Invalid_object      make_with_details &amp;lt; at &amp;gt;3   Segmentation violation:
&amp;lt;00000000034B25E0&amp;gt;  (From GB_ACTION_SEQUENCE_INFO)
                                           Operating system signal.
Fail
-------------------------------------------------------------------------------
Invalid_object      make_with_details &amp;lt; at &amp;gt;3
&amp;lt;00000000034B25E0&amp;gt;  (From GB_ACTION_SEQUENCE_INFO)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      string_to_action_sequence_info &amp;lt; at &amp;gt;10
&amp;lt;000000000346F5D8&amp;gt;  (From GB_EVENT_UTILITIES)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      prepass_xml &amp;lt; at &amp;gt;43
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      prepass_xml &amp;lt; at &amp;gt;37
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      prepass_xml &amp;lt; at &amp;gt;13
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      prepass_xml &amp;lt; at &amp;gt;13
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      prepass_xml &amp;lt; at &amp;gt;13
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      parse_directories &amp;lt; at &amp;gt;25
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      generate &amp;lt; at &amp;gt;19
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Routine failure.
Fail
-------------------------------------------------------------------------------
Invalid_object      generate &amp;lt; at &amp;gt;5            Unexpected harmful signal
(Segmentation violation):
&amp;lt;000000000346F5D8&amp;gt;  (From GB_CODE_GENERATOR)
                                           Eiffel run-time panic.
Panic
-------------------------------------------------------------------------------

esbuilder: dumping core to generate debugging information...

esbuilder: PANIC CASCADE: Unexpected harmful signal (Segmentation
violation) -- Giving up...

esbuilder: PANIC: Unexpected harmful signal (Segmentation violation) ...

esbuilder: system execution failed.
Following is the set of recorded exceptions.
NB: The raised panic may have induced completely inconsistent information:

Operating System Windows 7 but also on Ubuntu!
&lt;/pre&gt;</description>
    <dc:creator>giorgio misuri</dc:creator>
    <dc:date>2013-04-24T13:33:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10954">
    <title>HASH_TABLE:  hash_code from single attribute of the key</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10954</link>
    <description>&lt;pre&gt;In HASH_TABLE there is a warning:

warning: "[
     Modifying an object used as a key by an item present in a table will
     cause incorrect behavior.  If you will...

table: HASH_TABLE [VITP_WIDGET, VITP_ITEM]


class
     VITP_ITEM
inherit
     HASHABLE
feature -- Access
     name: STRING_8
     hash_code: INTEGER
          do
               Result := name.hash_code
          end
end


I use the VITP_ITEM "as the key" but the hash_code comes from a STRING.  Can I modify the VITP_ITEM as long as the `name' (which is "really" the key) never changes or is this still bad?



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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-04-24T03:24:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10953">
    <title>Confusing HASH_TABLE precondition violation</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10953</link>
    <description>&lt;pre&gt;table: HASH_TABLE [VITP_WIDGET, VITP_ITEM]


class
     VITP_ITEM
inherit
     HASHABLE
feature -- Access
     name: STRING_8
     hash_code: INTEGER
          do
               Result := name.hash_code
          end
end

I get a precondition violation when calling `extend':  "not present: not has (key)"
In the debugger, the set of `keys' has 12 items, non of which is the object that was passed as `key' to `extend'.  Also, none of the keys already in the table have a name equivalent to the name of the item passed in.  I don't understand why the table is saying it *does* have the key?




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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-04-24T03:22:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10952">
    <title>EV_MODEL problems</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10952</link>
    <description>&lt;pre&gt;Well, I fixed the 4 errors listed in the previous posts.  Now I have 127!

They come from [the many] descendants of VITP_WIDGET, which is an EV_MODEL_WORLD.  All the errors again originate in the use of ARRAY in EV_MODEL_WORLD.   Void-safety with any class that uses ARRAY seems unusable!  I wonder how many of the EV_xxx classes suffer from this.





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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-04-24T02:05:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10951">
    <title>Creation instruction applies to target of a deferred type</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10951</link>
    <description>&lt;pre&gt;Similar to my other post.

deferred class VITP_WIDGET
inherit
  EV_MODEL_WORLD
feature {NONE} -- Initialization
  frozen make (a_item: like vitp_item)
     -- set the item, and other stuff
feature -- Access
  vitp_item: VITP_ITEM


It seems the solution is similar to what I used in the other post--add bogus creation feature and redefine default create.  But, this is not desired; this class should be deferred (but cannot be because I need a creation routine) and `vitp_item' is also deferred so, again, I have to create a stupid dummy object in the redefined `default_create' which should never be called!

What am I missing here?



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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-04-24T01:56:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10950">
    <title>Call to improper feature</title>
    <link>http://comments.gmane.org/gmane.comp.lang.eiffel.ise/10950</link>
    <description>&lt;pre&gt;class BORDER   -- as in a frame around a picture
inherit
  EV_MODEL_WORLD
create
  make
feature {NONE} -- Initialization
  make (a_widget: ATTACK_UNIT_WIDGET)
       ...
feature -- Access
  widget: ATTACK_UNIT_WIDGET

The intent is to allow creation of this figure-world only by setting the `widget'.  However, void-safety  give a VGCC error, requiring the additional the addition of `list_make' as a creation feature.  But, I don't want a BORDER to be created without a widget.  Okay, restrict creation using:

create {BORDER}
  list_make

But now `widget' is "not properly set" (VEVI).  So, I have to redefine `default_create' setting `widget' to a bogus object.  The redefined `default_create' feature is worthless and should never be called.  

Can anyone explain why I must do this?  (It seems to all point back to the creation of an ARRAY.  This sure makes designing in Eiffel more difficult than it should be.  This needs a fix.)



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

&lt;/pre&gt;</description>
    <dc:creator>Jimmy Johnson</dc:creator>
    <dc:date>2013-04-24T01:56:17</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.eiffel.ise">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.eiffel.ise</link>
  </textinput>
</rdf:RDF>
