gmane.comp.lang.eiffel.smalleiffel

non-expanded external type

Paolo Redaelli — 2008-11-30T22:52:13

I was playing with external type example wondering what's the indetended usage of non-expanded external type. Current snapshot tells me that: "Classes with an external type must be expanded or deferred." I naively put together a little example to test non-expanded external classes that I have attached here. Is there any documentation about those types? The wiki page on external types is not helpful to me. Thanks in advance Paolo

A proposal for NATURAL syntax

Paolo Redaelli — 2008-11-18T08:15:52

I have a little proposal for NATURALs. People coming from other languages will find code like n8 := 1.to_natural_8 n16 := 1.to_natural_16 n32 := 1.to_natural_32 n64 := 1.to_natural_64 a little "verbose" or cumbersome to use. Someone could also wonder if such a syntax will be "optimized away" by the compiler either Eiffel or C. Chances are high that an unoptimized implementation will allocate an unnecessary temporary integer on the stack. I would like to propose a tentative syntax for Gnu-Eiffel that could look like: n8 := {NATURAL_8 1} n16 := {NATURAL_16 1} n32 := 1U n64 := {NATURAL_64 1} People reading code find "perfectly natural" to infer the type of an integer constant "from the context"; we have already lengtly discussed why inferring the type of an object from its context is not good for program clarity or even The proposal for 8,16 and 64 bit naturals is modelled after the usual in-place creation of objects. Syntax for 32bit is inspired from both C and SmartEiffel unicode string syntax. In f

Unicode characters

Paolo Redaelli — 2008-11-18T07:52:38

I've read Glib section for Unicode. As far as I can understand Unicode characters are unsigned 32 bit values. Currently UNICODE_STRING actually uses signed values. AFAIK the occurrences of INTEGER_32 referring to character codes shall be changed to NATURAL_32. Is it right? Thanks in advance for your attention Paolo

Source code encoding

Paolo Redaelli — 2008-11-17T15:41:17

Is the following correct? Gnu-Eiffel source-code is expected to be encoded either ASCII UTF8. In case of UTF8 encoding all non-ASCII characters shall be enclosed into comments or in string manifest bodies. I fear there are some glitches in the previous sentence, in fact: ======= class US -- i.e. Unicode String creation make feature make is do stampa(U"Tànti èuri: 1000€".as_utf8) stampa("Tànti èuri: 1001") end stampa (s: STRING) is local i: INTEGER do print("Printing '"+s+"' character-by-character:%N") from i:=s.lower until i>=s.upper loop std_output.put_character(s< at >i) std_output.put_character('-') i:=i+1 end std_output.put_new_line end end ======= When compiled produce: paolo< at >laboratorio:~/tmp$ compile us && ./a.out Printing 'Tànti èuri: 1000€' character-by-character: T-�-�-n-t-i- -�-�-u-r-i-:- -1-0-0-0-�-�- Printing 'Tànti èuri: 1000' character-by-character: T-�-�-n-t-i- -�-�-u-r-i-:- -1-0-0- paolo< at >laboratorio:~/tmp$ file us.e us.e: UTF-

Unicode source code?

Paolo Redaelli — 2008-11-04T09:30:59

I'm still working - in the few spare time that real life leaves me - on eiffel-gcc-xml. I'm updating it to work with latest SmartEiffel snapshots and to produce low-level wrappers that uses the plug-in mechanism. I noticed that XML_COMPOSITE_NODE "took the place" of XML_NODE and that attributes names and values are now Unicode strings. So my question is: can Eiffel source code be encoded in Unicode? If - as I suspect - it is not the case what's the preferred encoding? Since we are handling the XML representation of a C/C++ program/library I think that something as naive as print((U" arbitrary Unicode string from GCC-XML output").as_utf8) could be fine since it would end up producing ASCII with almost any conceivable output of gccxml. I already checked that UTF8 in comments is easily digested by compiler. Since I'm writing about encoding of SmartEiffel source file I would like to open a little discussion about a question that has been puzzling me for a while. I remember that in OOSC2 Meyer told th

Frozen STRING's infix "< at >"

Paolo Redaelli — 2008-10-29T16:50:26

Is there a particular reason to have STRING's infix "< at >" frozen? I was going to create an "easier-to-read" heir of STRING, named LINKED_STRING, useful to implement fast concatenation and fast message-formatter-like features, more or less like the attached source. The idea was to allow code like this: print(linked_string("My foo") | my_string | " is good "| another_string) or something like: print(linked_string ("inline < at >(1) < at >(2) (< at >(3) a_structure) { a_structure->< at >(4); }") # c_type # (a_structure_name+"_get_"+c_field) # structure_type # c_field)

conversion STRING to REAL_32

Raphael Mack — 2008-10-19T10:42:23

Hello, is there any feature to convert a STRING into a REAL_32? Else I suggest to add a to_real_32 in class STRING. Thanks for every comment, Rapha

exit code of "se test"

Raphael Mack — 2008-10-19T09:01:20

Hello, when executing "se test" I get output of failed tests (c compilation did not succeed), which means, that some tests did not work: ========================== In directory "/home/r/eiffel/eiffel-libraries/trunk/eiffel-gsl/test/". test_complex011.o: In function `r25make': test_complex011.c:(.text+0x96ef): undefined reference to `se_cmpT54' collect2: ld gab 1 als Ende-Status zurück se test (eiffeltest): Error while running: se c -all_check test_complex01.e -o test_complex01.exe (Return status was 1) se test (eiffeltest): Unable to compile "test_complex01.e". Command used: se c -all_check test_complex01.e -o test_complex01.exe In directory "/home/r/eiffel/eiffel-libraries/trunk/eiffel-gsl/test/". ========================== Now, the call to "se test" returns 0. Is there a good reason why? - else I suggest to return 1 if at least one test failed. Thanks, Rapha

serc

Raphael Mack — 2008-10-18T20:11:47

Hi, I have strange settings in my serc, since I am cross-compiling my se app for an arm target. The problem now is, that I want to pass option "--sysroot=somepath" to the gcc call. How can I do this? Just writing the option into the serc file does not work, as everything from "--" is treated as comment and therefore ignored... Thanks, Rapha

UNICODE support

Raphael Mack — 2008-10-05T11:25:43

Hi, I am working with unicode, and would request the following features: - improve unicode debugging, i. e. allow displaying unicode strings in sedb - add support for inspect using unicode strings. both should behave as these do with (non-unicode) STRINGs. Thanks, Rapha

XML_PARSER

Raphael Mack — 2008-10-03T11:33:45

Hello there, I use the XML_PARSER, as shown in the tutorial/xml and got the following assertion violation: ====================================== Garbage Collector at work. dispose called (during sweep phase) ====================================== dispose FILE_PROTOCOL Current = FILE_PROTOCOL#0x8222118 [ error = Void stream = Void instream = Void outstream = Void ] line 92 column 28 file /home/r/SmartEiffel/lib/net/protocol.e To solve this, I suggetst to add: if url.is_connected then url.disconnect end to feature disconnect in UNICODE_PARSER_BUFFER. (I'm not sure, the conditional is required, I guess not.) The tutorial/xml does not compile at the moment as Cyril changed the XML code to use UNICODE_STRING now. I attach a patch, which solves this, may be someone can apply it. And another problem I have is, that the XML_PARSER cannot parse UNICODE correctly. Here I did not try to fix the problem, but attach an example xml file, which uses UTF-8 multib

compiling plugin c code

Raphael Mack — 2008-10-01T21:12:44

Hi, I am playing with libpng, which uses setjmp and therefore includes setjmp.h. For some reasons, it requires that setjmp.h is not included already and that conflicts with the generated C code. I use the libpng stuff only in a .c file of my plugin but SE seems to inline the c code from the plugin file into its generated code. Why is this? - Is there a way to compile the c modules from the plugin separately and just link them together at the end? Then everything whould be fine, I think. Thanks in advance, Rapha

Mail acknowledging my SmartZilla account doesn't arrive

2008-09-25T16:50:23

I've tried to create a SmartZilla account this afternoon (using my E-mail address above). The E-mail containing the confirmation instructions has not arrived, and neither has the mail resulting from me subsequently requesting a new password - when I realised that the welcome E-mail had probably not been sent or got lost. I've checked that nothing of the kind has been quarantined as spam here. Sorry to trouble the mailing list with this, but perhaps it is a general problem? John A. Murdie Department of Computer Science University of York UK

SmartEiffel / gcc 4 bug

Frederic Merizen — 2008-09-24T20:44:21

Hi list, I just spent a good deal of time testing the development version of SmartEiffel on various recent Linux distros with 4.2 or 4.3 gccs (including Ubuntu 8.04 and Fedora 9). Everything worked to satisfaction - except that I wasn't satisfied because I was hoping to catch /the bug/ in action. That's when it dawned on me. I found out what was wrong with our code (wrong handling of signed integer overflows) and fixed it mid-july of 2007. But se 2.3 was released in june 2007, so it obviously still has the bug. Executive summary : - SmartEiffel 2.3 and less produce C code with (slightly) incorrect integer handling that breaks optimisations in gcc 4.2 and above. Workaround: only use -O1 optimization - The fix has been in the repository for more than one year and it works with the 4.2 and 4.3 series of gcc, hopefully there will be a SmartEiffel release soon. Cheers

SmartZilla?

Aleksa Todorovic — 2008-09-16T17:11:39

Is SmartZilla still active?

Compilink trunk version?

Aleksa Todorovic — 2008-09-15T13:50:15

Hi! I'm working on Windows, using VisualStudio compiler (cl). I've just checked out svn trunk version, but I'm not sure how to compile it. I tried to download nightly build, but it is of no use - it doesn't containt install/germ/*.c files. After that, I downloaded 2.3 version, and picked up install/germ files from there. After compilation of compile_to_c, I the message which follows this post. What am I supposed to do? Maybe nightly build should, beside files from svn, also contain install/germ/*.c files? System call ""D:\dev\SmartEiffel\svn\trunk\bin\compile_to_c.exe" -boost -no_gc - relax -o compile_to_c.exe compile_to_c". ****** Error: Forbidden creation call (i.e. exportation rules violated). Creation is only allowed from {RECYCLING_POOL}. The source lines involved by the message are the following: Line 303 column 4 in FAST_ARRAY (D:\dev\SmartEiffel\svn\trunk\lib\storage\collec tion\fast_array.e): create Result.make(max - min + 1) ^ Line 13 column 12 in STACK (D:\dev\SmartEiffel\s

TYPED_INTERALS

Raphael Mack — 2008-09-13T16:08:13

Hi, with the latest svn (and it seems to be in for quite a while now) of the compiler I get some compiler errors from the C compiler about missing types. Actually it comes in, by using XML_FILE_REPOSITORY. Has there been a change in the handling of typed internals recently? BTW, the tutorial/storable/example* trigger the problem, also. Cheers, Rapha

SmartEiffel back to debian GNU/Linux ?

Xavier Oswald — 2008-09-11T11:19:35

Hi, Well, as it is my first mail on these lists, I will present myself quickly. My name is Xavier. Im working on the Lisaac compiler which has lot of common points to smarteiffel. First version of Lisaac was written in SmartEiffel ;). Im a Debian maintainer (quite an official Debian developer). So I was looking for the status of smarteiffel 1-2 in Debian. It has been removed from Debian since nobody was taking care of it and because the lacks of users installing it. So my question is, do you think it is usefull to re-add it to Debian ? Are there some Debian users on these lists interesting to having it in Debian ? So if I get positive answers, I will re-add and maintain it in Debian. Greetings,

Semantics of agents, expanded classes and functions

2008-09-11T09:42:19

I would like to thank everyone who gave specific solutions and advice about REFERENCE and agents, delivering values rather than references. These dealt with working around the problems shown. However there appears to be a deeper problem in semantics than those specifics. I posed the question about agents acting differently than the identical code generating them to the activation of the code itself. The current implementation of agents also demonstrates differences between a feature delivering an expanded value as a function or as an actual entity. If I remember correctly, OOSC states that this should not be so. The position seems to depend on the evaluation of the expression delivering an expanded type or a function delivering an object, as an agent expression. In ETL3 Meyer lists the reasons for using expanded types as:- Realism in modeling external world objects, especially when you want to describe objects that have sub-objects. Possible efficiency gain. Basic types. Interface with ot

NUMBERs and CAS

Paolo Redaelli — 2008-09-10T17:15:12

I'm just wondering if it is "feasible" to inherit from NUMBER to implement a simplified Computer Algebra System like Ginac (http://www.ginac.de/). The "inner" design of its expressions - the one hidden by the ex type, is akin to "our" NUMBER class. Except that they had to had a layer to hide reference counting and other amenities that are avoided from the beginning by Eiffel, thanks to its design and Garbage Collector.

Agents and Function Pointers

Remi Meier — 2008-09-05T23:18:54

Hello everyone, I'm kinda new to SmartEiffel and I've got a question concerning function pointers and how to call them. I'm trying to create a plugin system for my own application. A lot of these plugin systems use shared libraries (DLLs and SOs) so that others can write them independently of the application, which can just load the plugins and use them according to a specified interface (in my case this would be a standard C interface). So what I want to do is about this: 1. load a shared library 2. get the addresses to the functions I want to use 3. use them 4. close the shared library 1., 2. and 4. are solved (a wrapper to dlopen/dlsym/dlclose), the problem is now number 3. I'm not familiar with the whole class set of SE and on the web, so it could be that I've overseen the obvious solution. In that case, please excuse me :) What I want to do is actually just convert the pointer given by dlsym to a PROCEDURE[TUPLE[...]]. But I don't see any possibility of how to do this... There is