OpenEuphoria

2. Re: 3.0.3

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> May 06, 2007
• 743 views

Robert Craig wrote:
> 
> If no one has any objections, in a few days I'll 
> take a snapshot of the source and start preparing a 3.0.3 release.
> There have been a number of small improvements and bug fixes
> since 3.02 (February):
> 
>   - find_from() / match_from()  (Matt Lewis)
> 
>   - change to include path search (C.K. / Matt Lewis)
> 
>   - ex int.ex now works, for anyone who wants to easily experiment
>     with changes to the front end, while executing programs at full speed
>  
>   - bugs reported by Deschenes and Kluss have been fixed 
> 
>   - I've added some new documentation
> 
>   - various other things by Matt Lewis and myself
> 
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

Are you going to fix the bug where environment variables (like EUDIR) that have
accented characters inside their value are improperly reported by getenv()
under Windows (at least XP)?

For instance, if a path was entered with a e acute,, getenv() returns it
with a U acute, and include files are not found if the variable happened to
be EUINC.

Suggested fix: under Windows, if a path gives a file open failure in 
path_open(), and has chars in the 128-255 range, then convert it using 
CharToOEM() API and try again.

CChris

4. Re: 3.0.3

• Posted by Andrew Katz <Akatz712 at gmail.com> May 09, 2007
• 764 views
• Last edited May 10, 2007

Please include the file bit.e. I use this and it is a logical extension of the
Euphoria language.

B.S. Computer Science, 1978
Rensselaer Polytechnic Institute (RPI)

6. Re: 3.0.3

• Posted by Juergen Luethje <j.lue at gmx.de> May 11, 2007
• 749 views

Helo Rob,

maybe you can add something like the following to 'misc.e':

global constant
   FALSE = 0,
   TRUE  = not FALSE

global type boolean (object x)
   if integer(x) then
      return x = FALSE or x = TRUE
   else
      return FALSE
   end if
end type

I think it would be pretty useful.

Regards,
   Juergen

8. Re: 3.0.3

• Posted by Robert Craig <rds at RapidEuphoria.com> May 11, 2007
• 775 views

Juergen Luethje wrote:
> maybe you can add something like the following to 'misc.e':
> }}}
<eucode>
> global constant
>    FALSE = 0,
>    TRUE  = not FALSE
> 
> global type boolean (object x)
>    if integer(x) then
>       return x = FALSE or x = TRUE
>    else
>       return FALSE
>    end if
> end type
> </eucode>
{{{

> 
> I think it would be pretty useful.

It would be useful, but if we add it now,
it will trigger error messages in a lot of existing code,
since boolean, TRUE and FALSE are already declared
as globals, and used, by many programs that currently include misc.e.
Maybe we should instead create a new "standard types" include file.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

10. Re: 3.0.3

• Posted by Juergen Luethje <j.lue at gmx.de> May 11, 2007
• 750 views

Robert Craig wrote:

> Juergen Luethje wrote:
> > maybe you can add something like the following to 'misc.e':
> > }}}
<eucode>
> > global constant
> >    FALSE = 0,
> >    TRUE  = not FALSE
> > 
> > global type boolean (object x)
> >    if integer(x) then
> >       return x = FALSE or x = TRUE
> >    else
> >       return FALSE
> >    end if
> > end type
> > </eucode>
{{{

> > 
> > I think it would be pretty useful.
> 
> It would be useful, but if we add it now,
> it will trigger error messages in a lot of existing code,
> since boolean, TRUE and FALSE are already declared
> as globals, and used, by many programs that currently include misc.e.

I see.

> Maybe we should instead create a new "standard types" include file.

Oh yes, I think that is a good idea.

Regards,
   Juergen

12. Re: 3.0.3

• Posted by Derek Parnell <ddparnell at bigpond.com> May 12, 2007
• 722 views

Jeremy Peterson wrote:
> 
> Juergen Luethje wrote:
> > 
> > Helo Rob,
> > 
> > maybe you can add something like the following to 'misc.e':
> > }}}
<eucode>
> > global constant
> >    FALSE = 0,
> >    TRUE  = not FALSE
> > 
> > global type boolean (object x)
> >    if integer(x) then
> >       return x = FALSE or x = TRUE
> >    else
> >       return FALSE
> >    end if
> > end type
> > </eucode>
{{{

> > 
> > I think it would be pretty useful.
> > 
> > Regards,
> >    Juergen
> 
> Why not just
> 
> TRUE = 1 

Because it removes implementation dependancies.

It is generally accepted that when the concept 'FALSE' is implemented as an
integer, the value zero is used. However, there are quite a few different
implementations of 'TRUE', some use 1, some -1, and some use every non-zero
value. By defining 'TRUE' as 'not FALSE' it will work with any implementation.


Alsoh due to a quirk in the way that short-circuit IF evaluations work, it can
be made to execute faster when the conditions are separated out ...

global constant
   FALSE = 0,
   TRUE  = not FALSE

global type boolean (object x)
   if not integer(x) then return FALSE end if
   if x = FALSE return TRUE end if
   if x = TRUE  return TRUE end if
   return FALSE
end type

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

14. Re: 3.0.3

• Posted by Derek Parnell <ddparnell at bigpond.com> May 12, 2007
• 704 views

Pete Lomax wrote:
 
> FWIW I prefer this, which I got from someone on this forum:
> }}}
<eucode>
> constant TRUE=(1=1),  -- for Eu, 1 (aka <>0)
>          FALSE=(1=0)  -- for Eu, 0
> </eucode>
{{{

> It is succinct and programming-language-independent.

LOL ...  thank you. Yes, this is the way I code in win32lib.
 
> > Also due to a quirk in the way that short-circuit IF evaluations work

> Crikey! I really (really!) thought that

if integer(x) and (x=FALSE or x=TRUE) then return TRUE end if
     return FALSE

> would be faster, but you are right and in my first test some 35% faster.
> I thought I understood this, what is this "quirk" am I missing?

It was brought to my attention some time ago during that programming contest I
ran for you guys. I haven't looked into the generated code for it but I guess
that it's not as efficient as it could be. In fact, I'm not sure that there are
any optmizations done to the code after it has been generated. Maybe this is an
openning for a future enhancement?

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

16. Re: 3.0.3

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> May 12, 2007
• 722 views

Derek Parnell wrote:
> 
> Jeremy Peterson wrote:
> > 
> > Juergen Luethje wrote:
> > > 
> > > Helo Rob,
> > > 
> > > maybe you can add something like the following to 'misc.e':
> > > }}}
<eucode>
> > > global constant
> > >    FALSE = 0,
> > >    TRUE  = not FALSE
> > > 
> > > global type boolean (object x)
> > >    if integer(x) then
> > >       return x = FALSE or x = TRUE
> > >    else
> > >       return FALSE
> > >    end if
> > > end type
> > > </eucode>
{{{

> > > 
> > > I think it would be pretty useful.
> > > 
> > > Regards,
> > >    Juergen
> > 
> > Why not just
> > 
> > TRUE = 1 
> 
> Because it removes implementation dependancies.
> 
> It is generally accepted that when the concept 'FALSE' is implemented as an
> integer, the value zero is used. However, there are quite a few different
> implementations
> of 'TRUE', some use 1, some -1, and some use every non-zero value. By defining
> 'TRUE' as 'not FALSE' it will work with any implementation.
> 
> 
> Alsoh due to a quirk in the way that short-circuit IF evaluations work, it can
> be made to execute faster when the conditions are separated out ...
> 
> }}}
<eucode>
> global constant
>    FALSE = 0,
>    TRUE  = not FALSE
> 
> global type boolean (object x)
>    if not integer(x) then return FALSE end if
>    if x = FALSE return TRUE end if
>    if x = TRUE  return TRUE end if
>    return FALSE
> end type
> </eucode>
{{{

> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

Isn't

global constant
FALSE = 0,
TRUE = not FALSE

global type boolean(integer x)
return x = x = TRUE
end type

even faster?

CChris

18. Re: 3.0.3

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> May 12, 2007
• 736 views

Derek Parnell wrote:
> I haven't looked into the generated code for it but I guess
> that it's not as efficient as it could be. In fact, I'm not sure that there
> are any optmizations done to the code after it has been generated. Maybe 
> this is an openning for a future enhancement?
I see, I dumped the il to have a look see. These listings are based on 
my hacked 2.5 frontend, but I've checked 3.0.0 and the results seem to
be the same. Derek's routine:

global type boolean (object x)
     if not integer(x) then return FALSE end if
     if x = FALSE then return TRUE end if
     if x = TRUE  then return TRUE end if
     return FALSE
 end type
--il code:
{NOVALUE,99,M_NORMAL,SC_GLOBAL,U_UNUSED,1,"boolean",0,TYPE,52,0,0,-1,0, -- rtn
98
    {IS_AN_INTEGER,99,100 --1: tmp 100 := IS_AN_INTEGER(x)
    ,NOT_IFW,100,10 --4: NOT_IFW tmp 100 (10)
    ,RETURNF,98,94 --7: RETURNF boolean, FALSE
    ,EQUALS_IFW,99,94,17 --10: x EQUALS_IFW FALSE (17)
    ,RETURNF,98,96 --14: RETURNF boolean, TRUE
    ,EQUALS_IFW,99,96,24 --17: x EQUALS_IFW TRUE (24)
    ,RETURNF,98,96 --21: RETURNF boolean, TRUE
    ,RETURNF,98,94 --24: RETURNF boolean, FALSE
    ,BADRETURNF --27: BADRETURNF
    }}

--My routine:
type boo2(object x)
    if integer(x) and (x=FALSE or x=TRUE) then return TRUE end if
    return FALSE
end type
--ilcode:
{NOVALUE,107,M_NORMAL,SC_LOCAL,U_UNUSED,1,"boo2",0,TYPE,1455,0,0,-1,0, -- rtn
106
    {IS_AN_INTEGER,107,108 --1: tmp 108 := IS_AN_INTEGER(x)
    ,SC1_AND_IF,108,108,29 --4: SC1_AND_IF(tmp 108,tmp 108) --> 29
    ,EQUALS,107,94,109 --8: tmp 109 := EQUALS(x,FALSE)
    ,SC1_OR,109,109,23 --12: SC1_OR(tmp 109,tmp 109) --> 23
    ,EQUALS,107,96,110 --16: tmp 110 := EQUALS(x,TRUE)
    ,SC2_OR,110,109 --20: SC2_OR tmp 110,tmp 109
    ,IF,109,29 --23: IF tmp 109 (29)
    ,RETURNF,106,96 --26: RETURNF boo2, TRUE
    ,RETURNF,106,94 --29: RETURNF boo2, FALSE
    ,BADRETURNF --32: BADRETURNF
    }}

Theoretically, the SC1_AND_IF could (in this case) be a plain IF, the 
EQUALS/SC1_OR pair a NOTEQ_IFW to the return TRUE statement, and the 
EQUALS/SC2_OR/IF triple an EQUALS_IFW to the return FALSE statement, 
I think:

{IS_AN_INTEGER,107,108 --1: tmp 108 := IS_AN_INTEGER(x)
    ,IF,108,18 --4: IF tmp 108 (18)
    ,NOTEQ_IFW,107,94,15 --7: x NOTEQ_IFW FALSE (15)
    ,EQUALS_IFW,107,96,18 --11: x EQUALS_IFW TRUE (18)
    ,RETURNF,106,96 --15: RETURNF boo2, TRUE
    ,RETURNF,106,94 --18: RETURNF boo2, FALSE
    ,BADRETURNF --21: BADRETURNF
    }

Easier said than done, no doubt.

Regards,
Pete
PS I should perhaps point out that the latter il obviously ought to beat the
current il for the same source, though I doubt it will improve any on the il
emitted for Derek's code, which looks spot on to me. Both first and last ils
execute the same number of il instructions in all cases. The only reason the
latter is smaller is it encodes only two return statements instead of four.

20. Re: 3.0.3

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> May 13, 2007
• 738 views

Derek Parnell wrote:
> 
> CChris wrote:
>  
> > Isn't
> }}}
<eucode>
>  global constant
>  FALSE = 0,
>  TRUE = not FALSE
>  
>  global type boolean(integer x)
>  return x = x = TRUE
>  end type
>  </eucode>
{{{

> > even faster?
> > 
> 
> Probably, but is not exactly clear at first reading. You have to think it
> through
> to see that it works. The primary purpose of any programming language ought
> to be to help communicate your intentions to humans who read the code, so I
> recommend that coders, as a first priority, try to make code clear before
> trying
> to make it as fast as possible.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

I agree with this statement in 90% of cases. The main exception, which covers
the case at hand, is for low level stuff which is executed implicitly tens or
hundreds of times in about any reasonably complex programs - put
"Hello, world!" aside.

Why? Because these things are usually invisible, and hardly anyone bothers
to read them. Hence the readibility issue, for this class of utility code,
is probably less important han reliability and speed.

Nothing prevents anyone to code the human friendly way in a block comment,
and then put in actual code which works, but is a little less clear.

CChris
PS for Pete: anyway, I'd expect boolean() to crash if fed a sequence, so my
routine can indeed be used as a function. If you want a return of 0 for
sequences, then indeed it is not suitable.

22. Re: 3.0.3

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> May 13, 2007
• 733 views

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> <snip>
> 
> > PS for Pete: anyway, I'd expect boolean() to crash if fed a sequence, so my
> > routine can indeed be used as a function. If you want a return of 0 for
> > sequences, then indeed it is not suitable.
> 
> So you can use it yourself as a function, because it works like you expect.
> However, I think about 99% of the Euphoria programmers expect a type when
> used as function _not_ to crash, but to return either TRUE or FALSE.
> 
> Regards,
>    Juergen

Are you sure? It depends on the context, in my view, as an atom may be a
boolean and a sequence never can. This is why the argument type for a type
is not "object" by default, which your comment would imply.

At any rate it is easy to conform to that no crash policy:

global constant FALSE = 1=0
               ,TRUE = not FALSE

global type boolean(object x)
integer y
y=not compare(x, TRUE) -- y is TRUE iff x is, otherwise it is FALSE
return not compare(x, y)
end type

I'm afraid it would slow things down a little. Any benchmarks?

CChris

24. Re: 3.0.3

• Posted by Hayden McKay <hmck1 at dodo.com.au> May 14, 2007
• 743 views

i don't know it this has been mentioned but maybee you could improve 'incude'
statements.

if i have a main directory, say .\main and a subdirectory, say .\bin and then
some executable located in .\main\bin that uses some includes located in .\main,
euphoria cant properly handle theese includes. take for example;

.\main
  |
  +-------.\bin
  |          +--------> myprog.exw
  |          
  +--------> include1.ew
  +--------> include2.ew
  +--------> include3.ew

include1.ew has the following topline statements;

include include2.ew
include include3.ew

myprog.exw has the following topline statements;

include ..\include1.ew

euphoria crashes 'cause it cant find include2.ew or include3.ew in the current
directory. So I think that it would be nice if include statements check the
relative path of the file that they appear in rather than the current directory.