1. Porting Euphoria

Not that I've nearly scratched the surface of the Linus port, but I'm
curious as to any future plans for porting Euphoria. For Robert
specifically:

    - How has the Linux port been recieved?
    - Any thoughts about the Macintosh?
    - What about using Java bytecodes?

From what little I've seen, the BeOS looks really cool, but all the
libraries seem to be aimed at C++. And with the announcement that the Amiga
will not be built, the QNX/Amiga OS seems to have died.


For Pete:

I noticed you got a chance to come up for air the other day. Working on
Java? Way back when you had spare time you posted something about bytecodes
for Peuphoria - any consideration for Java bytecodes?

Has Peuphoria become stable? Will this version ever be stable/complete, or
is it headed back to the drawing board?


For anyone else:

Are there any in-progress open-source ports going on?


Thanks!

-- David Cuny

PS: Sorry about not getting work done on stuff like I promised - I seem to
be taking a sabbatical.

new topic     » topic index » view message » categorize

2. Re: Porting Euphoria

[resent via the web interface - ISP still broken.]

David Cuny writes:
>    - How has the Linux port been recieved?

I think it's too early to tell. Euphoria has been
distributed to shareware sites and advertised
as a language for DOS + Windows. Not many Linux
programmers are aware of it. That may be changing
however. As I type this, there's a huge horde of Linux hackers
descending on the RDS site. I just announced
2.2 beta for Linux on freshmeat.net and the RapidEuphoria
hit counter is going through the roof.

>    - Any thoughts about the Macintosh?

Not for the near future.

>    - What about using Java bytecodes?

Java byte codes are not a good match for
Euphoria semantics. I guess your point though,
is to facilitate porting to multiple
platforms and to let you substitute Euphoria for
Java on the Internet. I'm not planning to get into
those things right now. After Linux, I want to
spend some time on platform-independent things
that will benefit all users.

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: Porting Euphoria

Robert Craig wrote:

>> - What about using Java bytecodes?
>
> Java byte codes are not a good match for
> Euphoria semantics.

My thinking is that the biggest stumbling block is mapping sequences
efficiently.

Despite the fact that a sequence can contain virtually anything, I think
people still use them to hold the same sort of data that other languages do:
strings, numeric arrays, and general structures.

Pete's already shown that, by paying attention to what's being placed into a
sequence, it's possible efficently represent character strings. I would
imagine that the same sort of procedure could also be applied to numeric
arrays.

In theory, then, strings and numeric arrays could be mapped fairly
efficiently.


> I guess your point though,
> is to facilitate porting to multiple
> platforms and to let you substitute Euphoria for
> Java on the Internet. I'm not planning to get into
> those things right now.

Pete?


> After Linux, I want to spend some time on
> platform-independent things that will benefit
> all users.

Great! My vote is still for OOP-like dot extentions.

*Ouch!* Jiri, stop hitting! blink


-- David Cuny

new topic     » goto parent     » topic index » view message » categorize

4. Re: Porting Euphoria

David Cuny writes:
>    - How has the Linux port been recieved?

I think it's too early to tell. Euphoria has been
distributed to shareware sites and advertised
as a language for DOS + Windows. Not many Linux
programmers are aware of it. That may be changing
however. As I type this, there's a huge horde of Linux hackers
descending on the RDS site. I just announced
2.2 beta for Linux on freshmeat.net and the RapidEuphoria
hit counter is going through the roof.

>    - Any thoughts about the Macintosh?

Not for the near future.

>    - What about using Java bytecodes?

Java byte codes are not a good match for
Euphoria semantics. I guess your point though,
is to facilitate porting to multiple
platforms and to let you substitute Euphoria for
Java on the Internet. I'm not planning to get into
those things right now. After Linux, I want to
spend some time on platform-independent things
that will benefit all users.

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: Porting Euphoria

My goodness, look at this, since yesterday, page accesses from
Freshmeat:

Download:   http://www.RapidEuphoria.com/v20.htm (301 hits)
Homepage:  http://www.RapidEuphoria.com/ (3187 hits)
Changelog:  http://www.RapidEuphoria.com/relnotes22.htm (27 hits)

Regards,
Greg Phillips

Robert Craig wrote:

> David Cuny writes:
> >    - How has the Linux port been recieved?
>
> I think it's too early to tell. Euphoria has been
> distributed to shareware sites and advertised
> as a language for DOS + Windows. Not many Linux
> programmers are aware of it. That may be changing
> however. As I type this, there's a huge horde of Linux hackers
> descending on the RDS site. I just announced
> 2.2 beta for Linux on freshmeat.net and the RapidEuphoria
> hit counter is going through the roof.
>
> >    - Any thoughts about the Macintosh?
>
> Not for the near future.
>
> >    - What about using Java bytecodes?
>
> Java byte codes are not a good match for
> Euphoria semantics. I guess your point though,
> is to facilitate porting to multiple
> platforms and to let you substitute Euphoria for
> Java on the Internet. I'm not planning to get into
> those things right now. After Linux, I want to
> spend some time on platform-independent things
> that will benefit all users.
>
> Regards,
>      Rob Craig
>      Rapid Deployment Software
>      http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

6. Re: Porting Euphoria

I still hope someone would let you play with a sparcstation  to compile the
solaris port- a great market for euphoria I'm sure.

Riwal Raude
rauder at thmulti.com

> -----Original Message-----
> From: Rob Craig [SMTP:rds at EMAIL.MSN.COM]
> Sent: Thursday, October 28, 1999 6:27 PM
> To:   EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject:      Re: Porting Euphoria
>
> [resent via the web interface - ISP still broken.]
>
> David Cuny writes:
> >    - How has the Linux port been recieved?
>
> I think it's too early to tell. Euphoria has been
> distributed to shareware sites and advertised
> as a language for DOS + Windows. Not many Linux
> programmers are aware of it. That may be changing
> however. As I type this, there's a huge horde of Linux hackers
> descending on the RDS site. I just announced
> 2.2 beta for Linux on freshmeat.net and the RapidEuphoria
> hit counter is going through the roof.
>
> >    - Any thoughts about the Macintosh?
>
> Not for the near future.
>
> >    - What about using Java bytecodes?
>
> Java byte codes are not a good match for
> Euphoria semantics. I guess your point though,
> is to facilitate porting to multiple
> platforms and to let you substitute Euphoria for
> Java on the Internet. I'm not planning to get into
> those things right now. After Linux, I want to
> spend some time on platform-independent things
> that will benefit all users.
>
> Regards,
>      Rob Craig
>      Rapid Deployment Software
>      http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

7. Re: Porting Euphoria

Greg Philips wrote:

> My goodness, look at this, since yesterday, page
> accesses from Freshmeat ...

Cool.

I wonder if any of them are subscribing to the mailing list. I could use
some help getting the GTK structures debugged. It would be nice if someone
wanted to wrap the Gnome libraries as well.

In case I didn't mention it, the GTK include files that I've developed for
Llama/GTK can be used for plain old GTK application development, without
having to deal with the Llama framework at all. The wrappers even do
transparent conversion of sequences to C strings - very handy.

The obligitory "Hello, World" program (taken from "GTK+/Gnome Application
Development") is included at the end of this e-mail. I didn't include the
portion of the code which reverses the button label when it's clicked,
because it relies on a typical C call that passes a value and returns a new
one through the same pointer:

   gtk_get_label_text( *control, &text )

instead of being implemented more properly as a function that returns a
pointer. That's one of the many things that needs to be fixed in the include
file.

-- David Cuny


-- hello, world demo of GTK

include api.gtk


function delete_event_cb( atom window, atom e, atom data )
    -- close the application
    gtk_main_quit()
    return 0
end function


procedure main()

    -- create a window with a button in it
    -- the label on the window says "hello, world!"

    atom window, button, label, result

    -- initialize gtk
    gtk_init( 0, {} )

    -- create a window
    window = gtk_window_new( GTK_WINDOW_TOPLEVEL )

    -- create a button
    button = gtk_button_new()

    -- create a label
    label = gtk_label_new( "Hello, World!" )

    -- put the label in the button
    gtk_container_add( button, label )

    -- put the button in the window
    gtk_container_add( window, button )

    -- set the window title and border width
    gtk_window_set_title( window, "Hello" )
    gtk_container_set_border_width( button, 10 )

    -- connect a callback to the window delete event
    result = gtk_signal_connect( window,
                                "delete_event",
                                routine_id("delete_event_cb"),
                                NULL )

    -- show all the widgets in the window
    gtk_widget_show_all( window )

    -- main event loop
    gtk_main()

end procedure

main()

new topic     » goto parent     » topic index » view message » categorize

8. Re: Porting Euphoria

Rob,
I have considered porting euphoria and I decided it would be easiest  to
        compile euphoria
to a language. I considered java and instead of byte codes I tought about
compiling to
classes. In most cases euphorias semantics fit easily into OO design patterns. I
think it would
be possible to translate most programs. I'm not certain about automatically but
I should think it
is. Also since Euphoria is a simple procedural language where only the data
structures are
complex it doesn't seem to hard.

eu              sequence s
                s = repeat( 'A', 100 )
                if
                s[1] = s[2]
                then
                        printf( 1, s );
                end if

jav             Sequence s;
                s = Sequence.repeat( 'A', 100 );
                if(
                s.get(1).equals( s.get(2) )
                ) {
                        File.printf( 1, s.toString() );
                }

Give me any small code fragment and I will translate it.

The hard part is defining the basic classes. Once they are defined then the
translation into
any OOP language is possible. And that means it can be compiled for any platform
etc.
-------------------------
Sincerely,
Mathew Hounsell

mat.hounsell at excite.com

new topic     » goto parent     » topic index » view message » categorize

9. Re: Porting Euphoria

Matthew Hounsell wrote:

> I have considered porting euphoria and I decided it
> would be easiest  to compile euphoria to a language.
> I considered java and instead of byte codes I thought about
> compiling to classes.

I'm playing around with writing a Euphoria to QBasic translator. There's a
lot of 'small detail' stuff to consider - reference counts, garbage
collection, etc. I just found out that QBasic doesn't seem to allow passing
user defined data types, so I might have to add a stack as well. Grumble...

The ultimate goal is to translate to Java, but I'm more familiar with
QBasic. I figure if I can do it in QBasic, I can do it in anything.

-- David Cuny

new topic     » goto parent     » topic index » view message » categorize

10. Re: Porting Euphoria

Robert, I have to admit this looks 'do-able'. If are able to keep your basic
classes' code
hidden, and provide a simple tojava.ex program in the /bin directory, I don't
have to explain
how useful this can be. First of all, you then support 4 platforms. People with
experience in
Java, can look at the translated Java code for help, and you can have all the
demo programs
run from your RapidEuphoria site. You can check if there is a market/demand for
Euphoria
within a certain OS, and the Java version, which will be the most 'less'
versions will be the
basic of the language. If it runs in EuJava, then it will run on any platform,
i.e. the Java
version, unlike all the other platforms, does not have a system-dependent
routines and alike.

How about it ? However, I do suggest, if you choose to launch this, you would
first finish the
Linux edition (i.e.. beta > complete edition) and provide the Java version,
together with the
core changes to the language. (such as changes in namespace) That is, Euphoria -
Generation
Three, back to basics blink

What's your vision on this ?

Ralf N.


> eu              sequence s
>                 s = repeat( 'A', 100 )
>                 if
>                 s[1] = s[2]
>                 then
>                         printf( 1, s );
>                 end if
>
> jav             Sequence s;
>                 s = Sequence.repeat( 'A', 100 );
>                 if(
>                 s.get(1).equals( s.get(2) )
>                 ) {
>                         File.printf( 1, s.toString() );
>                 }
>
> Give me any small code fragment and I will translate it.
>
> The hard part is defining the basic classes. Once they are defined then the
> translation into
> any OOP language is possible. And that means it can be compiled for any
> platform etc.
> -------------------------
> Sincerely,
> Mathew Hounsell
>
> mat.hounsell at excite.com




Ralf Nieuwenhuijsen

[[ Email ]]
    nieuwen at xs4all.nl
    ralf_n at email.com

[[ I-Seek-You ]]
   UIN: 9389920

[[ The Elevator ]]
    http://www.xs4all.nl/~nieuwen

new topic     » goto parent     » topic index » view message » categorize

11. Re: Porting Euphoria

Mathew Hounsell wrote:

>jav             Sequence s;
>                s = Sequence.repeat( 'A', 100 );
>                if(
>                s.get(1).equals( s.get(2) )
>                ) {
>                        File.printf( 1, s.toString() );
>                }

Bleacchh!!

>Give me any small code fragment and I will translate it.

Thank you, no.

new topic     » goto parent     » topic index » view message » categorize

12. Re: Porting Euphoria

Mathew Hounsell writes:
> Give me any small code fragment and I will translate it.

Ralf writes:
> Robert, I have to admit this looks 'do-able'. If are able to
> keep your basic classes' code hidden, and provide a
> simple tojava.ex program in the /bin directory, I don't have
> to explain how useful this can be.

There's no question that it's technically "do-able"
(although a lot of work) to convert Euphoria code
into any other language "X".
The resulting code in language X would be larger and
slower than what an X programmer would write by hand,
but it would work.

The main issues for RDS are business ones.

Any effort in this area would almost certainly
involve revealing, perhaps indirectly, our algorithms
for making a fast Euphoria interpreter, and we might
also have to provide the algorithms used in all
of the library routines (although putting them in a
*machine-code* .DLL would help - byte codes aren't
very secure). The translator would have to be limited
in the PD edition to translating 300 statements maximum.

Another issue is that once people translate their
Euphoria program into language X, they might
decide that it's easier just to modify the
language X code and forget about using the translator.
Maybe they'll decide to start learning language X, and
abandon Euphoria.

Translating to Java would restrict you to doing things that
are possible in Java. Last time I checked, that does *not*
include peeking and poking directly into memory,
dos_interrupts, and all sorts of stuff that's specific to
a particular operating system.

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

new topic     » goto parent     » topic index » view message » categorize

13. Porting Euphoria

Never release the code, you simply shouldn't do that.
Keep it in YOUR control.

-=-

But split it up in different packages.
One program that is written in pure C is the main interpreter.
It uses a special lib (that can be upgraded on itself) that has *machine*
specific code.
Not the routines used by the interpreter, but only small pieces of code,
where optimization is important stuffed in one library. (there would only be
a IBMPC lib and in the future maybe an UNIX or MAC lib)
It would also contain the built-in functions that are not OS specific (like
find () and append ()) but are only Machine specific. (proccesor specific)
One of the built-in functions already available at this point is called
something like load_library.
The standard include file dos32.e loads up the dos32 library and defines how
the data needs to converted to which datatypes, and which error messages are
used. They also provide the type checking.
You would also have a win32.e and maybe an OS2.e interface.
In these libraries you would find the built-in routines for DLL's, Graphics,
Mouse.
These libraries also can be updated independently.
If you wanne write a cross platform using OS-dependent routines, you need to
include both.
The libraries extensions (the dos32.e and the win32.e) have to sort out
which library routine is activated and which isn't.
The load_lib function off course stays available during the whole program.

-=-

Robert, what about wildcard including..

    include \plugins\*.e

I don't think I need to explain this..

-=-

What about the ability to initiate a routine and receive its routine ID or
error message from source code in sequence form passed to a routine.

    id = initiate_function ({" return length(s1) "}},"sequence s1")
    printf ("The lengths of TXT is %d",{call_func(id, "TXT"})

-=-

Null values.. not yet initializid vars have a value of NULL.
Vertical slicing will put NULL values where needed.
Operations performed on NULL stay NULL.
NULL is nothing.. puts (1, NULL) puts nothing.
Its its own data type.
Stuff declared as integer or atom can never be NULL.
Sequences can not be NULL, but may contain NULL values.
Object can be NULL through.
Each routine or function can decide for themselves what to do whenever one
of the arguments is NULL.
(Unlike some languages where a NULL argument means: not call
funciton/procedure)

-=-

Whatever you do, make us able to call lib files (as we can call DLL's under
win32, we need to call a standard type of library under dos32)

-=-

Sequence/Type specific constants.. eh ?
constants that are defined within a type declaration, can be used to slice
vars declared as that type only, or to pass as arguments whenever that
argument is declared of that type.

type bit (integer i)
constant ON   = 1,
                OFF = 0

    return i = ON or i = OFF
end type

procedure blabla (bit i)
end procedure

blabla (ON)
puts (1, ON)     -- Error: On is not declared yet!

-=-

Ralf
nieuwen at xs4all.nl

new topic     » goto parent     » topic index » view message » categorize

14. Re: Porting Euphoria

PMFJI, but one reason for releasing the source code would be
to allow for "offshoot" developments.  For example, creating
plugins, porting to atypical platforms, etc.

Steve


-----Original Message-----
From: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
To: Multiple recipients of list EUPHORIA <EUPHORIA at MIAMIU.ACS.MUOHIO.EDU>
Date: Friday, April 03, 1998 9:02 AM
Subject: Porting Euphoria


>Never release the code, you simply shouldn't do that.
>Keep it in YOUR control.
>

<snip>

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu