OpenEuphoria

2. Re: minimanual.pdf -- comments requested

• Posted by K_D_R Oct 13, 2015
• 2234 views

Please lose the "oE" abbreviation. Every time I see it, I think someone stumped a toe. It has a very negative visual appeal - rendered in the text with the bold "E", it looks as if it was drawn by a child with a black magic marker.

I do appreciate your effort to produce a mini-manual. I'll read it carefully tonight and try to offer more substantive comments.

Ken Rhodes

4. Re: minimanual.pdf -- comments requested

• Posted by xecronix Oct 14, 2015
• 2207 views

First, GREAT JOB! Anything that follows is an attempt to help, not criticize.

• The mongoose logo is the wrong color.
• The display example needs some more explanation as to why example 4 produces numbers and examples 1-3 produces text.
• For the file IO section, st2 should have details as to what valid values are.
• I've never installed the packages for OpenEuphoria. I've only installed from source. So, does WEE/GTK come with OpenEuphoria? If not should the minimanual make a reference as to how to get them?
• If this manual is for 4.1 should it make mention of memstructs?
• Should the minimanual link to the online manual for more detail on specif topics?

-xecronix

6. Re: minimanual.pdf -- comments requested

• Posted by petelomax Oct 14, 2015
• 2242 views

That is better, but I still don't like "oE", even in plain text. I can only assume it is pronounced like a child being sick! Why not just use Euphoria? On a fresh install, can you not just double-click on wee.exw? The opening example is five times too complicated. Start with message_box("This is Euphoria","My first program",MB_OK), or won't that work on Linux? Maybe puts(1,"Welcome to programming in Euphoria") any_key(), or string name = prompt_string("Enter your name") puts(1,"Hello "&name) any_key().

I don't like "converted into a binary application". I would say something like "of course you can share the source code of your application, but then it can only be run where openEuphoria has already been installed. Use Run|Bind from the Wee menu to create a standard/standalone executable application (intro on Linux, intro.exe on Windows) that anyone can run. I'd also drop the "A compiler makes a better performing application" from the Flexible section: it screams that interpretation is horribly slow, and it's not usually the real reason for compiling (distribution is).

oE is powerful. I get it, but a) it is just bragging and b) it is not really communicating anything. Perhaps a better approach is to say something like some languages are deliberately designed to be difficult, some have so many ways of doing things they inadvertently become difficult. Euphoria keeps things simple so you can concentrate on the problem you are trying to solve, rather than add a whole new layer of problems as part of the solution. There are many freely available examples that prove keeping things simple does not have to sacrifice being powerful and flexible.

It no longer works to promote Eu as "not OOP". Rather Eu provides many of the benefits of OOP but in a much simpler way. For instance it is easy to place some data and all the routines that can operate on it in a separate file, and limit what routines (or data) can be invoked (or seen) from the rest of the application. You can easily attach any routine_id to any data; there is no need to declare a class or carefully construct a complicated hierarchy of inheritance just to get the right routines to be associated with some particular data.

The lack of an index/table of contents limits the usefulness of this severely, imo.

page 7 "que". "9/5* C +32" (wierd spacing)
Page 13: spurious !
Page 16: "& str[6]" should probably be "& str[6..6]" or better yet "& str[6..$]"
Page 22: end if/print wrong indent *2

You can get your own back by reviewing my effort, if you can handle chm format files: https://bitbucket.org/petelomax/phix then navigate source -> docs -> phix -> phix.chm

Pete

8. Re: minimanual.pdf -- comments requested

• Posted by _tom (admin) Oct 14, 2015
• 2153 views

Critics are welcome and needed. This is already the third re-write of the minimanual.

Does the logo have to be brown?

The eyes have gone from brown to green; this corrects the problem that on the website the eyes look red and bloodshot on some monitors. (This was an old forum request.)

Next was an experiment in changing the banner for the oE website. The idea was that reducing the number of colors makes for a cleaner banner.

At one time orange and blue was suggested as official colors. The wordmark in the manual is now brown. It's time choose colors for oE_4.1

The wordmark is also using a different font. The offical workmark is using a commercial font. I am using the closest open font I could find.

Graphic artists, please help out.

Good point. Needs elaboration.

Not sure which section.

This minimanual assumes that Wee is bundled with oE. That means the euGTK engine is available on a Linux install.

Another assumption is that oE will be part of a special Linux package. Puppy Linux is GTK2 so Wee will not work. Porteus Linux does work with Wee. The odd thing about Porteus Linux is that the pdf reader does not read all of the graphics in my minimanual. I think a small download and quick burn to a USB drive will make for compelling demonstration.

It doesn't help that I don't understand memstructs. But, the idea was to go to 25-30 pages maximum.

Would memstructs "scare off" someone who is virtually new to programming and sees oE for the first time? Does this suggest an advanced minimanual targeted to advanced users?

I'm not sure that the toolchain Creole|Wkhtmltopdf can be made to link between files.

I now mention the full Reference Manual in the first paragraph. The Library Sampler chapter also refers to the full Reference manual.

10. Re: minimanual.pdf -- comments requested

• Posted by _tom (admin) Oct 14, 2015
• 2185 views

We can do a copy paste to your site. The more exposure the better.

_tom

12. Re: minimanual.pdf -- comments requested

• Posted by _tom (admin) Oct 14, 2015
• 2171 views

That says the manual is wrong. RTFM means "redact the fine manual"

14. Re: minimanual.pdf -- comments requested

• Posted by xecronix Oct 14, 2015
• 2139 views

Absolutely not! The logo can be whatever color you want. The reason to keep it brown is all about brand recognition and first impressions.

Maybe consider adding more details about st2?

fn = open(st1, st2) -- open file name st1 with mode st2 
                    -- e.g. "r" for read 

This feature is a big deal in my opinion. Some introduction I think is warranted because the feature helps OpenEuphoria standout from other high level languages.

16. Re: minimanual.pdf -- comments requested

• Posted by _tom (admin) Oct 16, 2015
• 2161 views

In general, all of your comments are valuable and will end up fixing the re-write of the MiniManual.

The Linux (bound|compiled) version does not open a terminal to execute a program. If you launch WEE from a terminal then at least you have that terminal to display output. Got to complain about this...

I have tried to come up with a short demo to show this:

First an included file: temp.e

namespace temp 
 
export atom New, Set, Get, Show, Convert   -- actions 
export enum Temp, Units                    -- data-objects 
export enum C, F                           -- fixed values 
 
-- these subroutines are hidden from the end user 
 
function set( object entity, integer item, object value ) 
    entity[2][item] = value 
    return entity 
end function 
    Set = routine_id( "set" ) 
 
function get( object entity, integer item ) 
    return entity[2][item] 
end function 
    Get = routine_id( "get" ) 
     
procedure show( object entity, integer item ) 
        if item = 1 then 
            printf(1, " %g", entity[2][1] ) 
        else 
            printf(1, entity[2][2] ) 
        end if 
end procedure 
    Show = routine_id( "show" ) 
 
 
function convert( object entity ) 
    if entity[2][2] = C then 
        entity[2][1] = entity[2][1] * 9/5 + 32 
        entity[2][2] = F 
    else 
        entity[2][1] = (entity[2][1] - 32 ) * 5/9 
        entity[2][2] = C 
    end if 
    return entity 
end function 
    Convert = routine_id( "convert" ) 
 
function new() 
    return { {New,Set,Get,Show,Convert}, {Temp,Units} } 
end function 
    New = routine_id( "new" ) 
 
-- this one function calls the desired subroutine when needed 
export function T( object action, object entity = "", integer item = 0 , object value = "") 
    if action = New then 
        return call_func( New, {} ) 
    elsif action = Set then 
        return call_func( Set, { entity, item, value } ) 
    elsif action = Get then 
        return entity[2][item] 
    elsif action = Show then 
        if item = 1 then 
            printf(1, " %g", entity[2][1] ) 
        elsif item = 2 then  
            if entity[2][2] = C then 
                printf(1, " oC" ) 
            else 
                printf(1, " oF" ) 
            end if 
        end if 
    elsif action = Convert then 
        return call_func( Convert, {entity} ) 
    end if 
    return 0 
end function 

Then the main file: hotness.ex

include temp.e 
 
printf(1, "First entity is inside a room\n" ) 
    sequence room = T(New) 
        room = T(Set,room,Temp,15) 
        room = T(Set,room,Units,C) 
    T(Show,room,Temp) T(Show,room,Units) 
        room = T(Convert, room ) 
    printf(1, "\n after temperature conversion\n" ) 
    T(Show,room,Temp) T(Show,room,Units) 
 
printf(1, "\nSecond entity is outside the building\n" ) 
    sequence outside = T(New) 
        outside = T(Set,outside,Temp,-5) 
        outside = T(Set,outside,Units,C) 
    T(Show,outside,Temp) T(Show,outside,Units) 

Ideas for short demos are welcome.

How are you looking at the PDF? On Linux Mint the default viewer shows a "table of contents" as a side pane automatically--no work required.

An index is going to take some work, but I can try.

Thanks, _tom

18. Re: minimanual.pdf -- comments requested

• Posted by jimcbrown (admin) Oct 31, 2015
• 1966 views

Alternatively, we could merge memstructs into the main branch.

I haven't heard any objections to this idea, other than my own.

20. Re: minimanual.pdf -- comments requested

• Posted by jimcbrown (admin) Nov 01, 2015
• 1943 views

I'm surprised. The 4.0.x line shouldn't have changed all that much since the last release....

22. Re: minimanual.pdf -- comments requested

• Posted by jimcbrown (admin) Nov 02, 2015
• 1887 views

Sounds like a reason to drop 4.0.6 and focus all our efforts on 4.1.0, instead of having to find and fix the same bugs in two codebases.

24. Re: minimanual.pdf -- comments requested

• Posted by jimcbrown (admin) Nov 03, 2015
• 1897 views

I really am leaning towards the view that we should focus all efforts into 4.1.0 and not into 4.0.6.

Forked into: 4.0 vs. 4.1