1. mac.exe
Ummmm.... My brother, well, he's a Mac guy. And he really thinks
Euphoria is neat. What is the likelihood of ex.exe or exw.exe running
under an emulator? Or, contrarily, how hard would it be to port it to
something like "mac.exe" or is that totally wacko?
snortboy
2. Re: mac.exe
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BDE5B0.195320C8
charset="iso-8859-1"
Noah Smith wrote:
> how hard would it be to port it to something like "mac.exe"
> or is that totally wacko?
Most of the C programs written for the PC assume that a memory address
remains fixed. But that's not the way it works on the Mac.
Instead of using memory pointers, the Mac uses memory handles. You get an
address that points to and address holding your memory address - a double
indirection. That's because the Mac handles memory, and does heap compaction
from time to time.
As a result, porting C programs from the PC to the Mac can be less than
trivial, especially if they rely heavily on pointers - and Euphoria and
Pete's Euphoria clone fall into that category.
I had hoped to write a Euphoria clone to run on the Mac, but abandoned the
project. If the Euphoria interpreter spit out bytecodes (or Java bytecodes),
portability would be much simpler.
-- David Cuny
------_=_NextPart_001_01BDE5B0.195320C8
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: mac.exe</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Noah Smith wrote:</FONT>
</P>
<P><FONT SIZE=3D2>> how hard would it be to port it to something =
like "mac.exe" </FONT>
<BR><FONT SIZE=3D2>> or is that totally wacko?</FONT>
</P>
<P><FONT SIZE=3D2>Most of the C programs written for the PC assume that =
a memory address remains fixed. But that's not the way it works on the =
Mac.</FONT></P>
<P><FONT SIZE=3D2>Instead of using memory pointers, the Mac uses memory =
handles. You get an address that points to and address holding your =
memory address - a double indirection. That's because the Mac handles =
memory, and does heap compaction from time to time.</FONT></P>
<P><FONT SIZE=3D2>As a result, porting C programs from the PC to the =
Mac can be less than trivial, especially if they rely heavily on =
pointers - and Euphoria and Pete's Euphoria clone fall into that =
category.</FONT></P>
<P><FONT SIZE=3D2>I had hoped to write a Euphoria clone to run on the =
Mac, but abandoned the project. If the Euphoria interpreter spit out =
bytecodes (or Java bytecodes), portability would be much =
simpler.</FONT></P>
<P><FONT SIZE=3D2>-- David Cuny</FONT>
</P>
</HTML>
------_=_NextPart_001_01BDE5B0.195320C8--
3. Re: mac.exe
snortboy:
>What is the likelihood of ex.exe or exw.exe running
>under an emulator?
theory says that if it's a *good* emulator, that it
will function as an emulator and emulate what it's
supposed to be emulating. ;)
what that means to me is, the likelihood _should_
be high with a good emulator, and low with a bad one.
>Or, contrarily, how hard would it be to port it to
>something like "mac.exe" or is that totally wacko?
>Cuny, David wrote:
>As a result, porting C programs from the PC to
>the Mac can be less than trivial, especially if
>they rely heavily on pointers - and Euphoria and
>Pete's Euphoria clone fall into that category.
okay, in this arena i know enough to be only dangerous,
but perhaps not correct. my recollection of ANSI C
intention/definition is such that, if you write
a program that is truly ANSI C and then recompiled
that program on another platform, it should work, no?
now of course, with all it's extreme optimization,
Euphoria wouldn't recompile cross-platform, and
PEU may not by now. but, what if, PEU was taken
back to a stage that was ANSIc and we began there?
>If the Euphoria interpreter spit out bytecodes
>(or Java bytecodes),
allright...
the way i understand bytecodes actual "function"...
ergo: how it does what it does...
every reserved word has a "universal" identifier
and after that point, each variable gets it's own
moniker. then an interpreter that understands
this universal language, reads these codes and
executes them in a linear fashion.
what we then need are 3 things:
1>interpreters (run time executors) for all platforms
that understand "universal"
2>translators for all platforms that take .e and
.ex files and spit out "universal"
3>the actual definition of "universal"
not necessarily in this order :>
#3 doesnt seem so bad... especially with EU...
it gets a little gnarly tho, because of the following:
the byte is a universally understood storage medium.
but a byte can only hold 256 individual values, meaning
no more than 256 reserved words and variables *combined*.
myself, i can use 256 variables alone, in a real big hurry,
not counting reserved words...
allright you say, lets use int. everyone has int, right?
well, int varies like *alot* not just between platforms,
but sometimes within platform as well. EU has enormous
int, but pascal is like -32K..32K (or -64..64 is it?)...
either way... pascal's is much much smaller...
well this descrepancy wouldn't be tolerable for this type
of affair.
we're left then with what i believe java prolly does..
char... actually dual char i think... sets of pairs
of characters representing reserved words.
well that's good you say, but what about our precious
variables, and data, and constants, and strings and
the like?
unless i'm mistaken again, we cheat. one of the reserved
word 'tokens' tells the translator(run time) that what
is to follow (and for how long) will be a value,
or a variable name, or a constant... one token for each
of these (and other) possibilites.
when you look at it from this standpoint, be my understanding
actually right or wrong of how "java" (or any other bytecode
language) does it, it begins not to look quite so daunting.
another thing that looking at it this way reveals, especially
with euphoria, is that 256 reserved words might actually
work out to be "alot"...
at this point i think i should pointout & clarify "reserved
word" here... that would be all EU builtin func/proc names,
as well as all the math/boolean/sequence operators.
we can leave the operators as they sit, no need to translate
them as they already have a value from 0-255...cool...
life made easy already...
now we simply give the reserved "words" a value from the ones
left over, and we'll need to reserve a couple more for helping
to define variables/values/constants. let's suppose we pick
12 as the number for "sequence". we need another number
to represent "how many of the following bytes are to be used
as the name of this variable" or, hrmmm... for that matter,
whitespace can be real damned handy here as i think about it.
not to mention the {} and the ','.
something like:
sequence abcd {m,a,r,y, ,h,a,d, ,a, ,l,i,t,t,l,e}
could be turned into 'universal' rather easily in the
translator parser.
12 65 66 67 68 (and then the { would let the parser
know that the data was coming... you get the idea)
here's the neat part... reverse translators...
since euph (DOS) already understand .e and .ex then
we need only to reverse the algorithm for the DOS mode
translator to take a set of bytecode/tokens and make
ex.exe run this newly generated .ex file. I see this
as being potentially handy, and perhaps powerfull indeed.
especially for the web... streaming euphoria? you could
make web pages that -executed- just like activeX and java
pages do...
how would this work? okay, lets say we start with saying
that from now on, .exb is the extension for Euphoria
eXecutable Bytecode. we then need exb.exe which is the
ex.exe bound with a bytecode (universal) interpretive
front end. the plugin would also be exb.exe.
someone downloads that, and associates *.exb with
exb.exe and whenever they click on a link that is like
www.poot.com/game.exb
netscape is already smart enough to search for filetype
associations and spawn the proper program.
viola!
getting excited yet?
i don't think it would be that hard to make a DOS translator
from universal->.ex and .ex->universal?!?!? would it???
</endLengthyReply>
sowwy, got longwinded...
--Hawke'
4. Re: mac.exe
Hawke wrote:
>okay, in this arena i know enough to be only dangerous,
>but perhaps not correct. my recollection of ANSI C
>intention/definition is such that, if you write
>a program that is truly ANSI C and then recompiled
>that program on another platform, it should work, no?
In the case of memory allocation, the answer is no.
>now of course, with all it's extreme optimization,
>Euphoria wouldn't recompile cross-platform, and
>PEU may not by now. but, what if, PEU was taken
>back to a stage that was ANSIc and we began there?
We're not talking about extreme optimization here, but the basic mechanism
used to implement sequences (pointers) and opcodes (function pointers). If
you got rid of that part, all you would have left would be an interpreter.
>>If the Euphoria interpreter spit out bytecodes
>i don't think it would be that hard to make a DOS translator
>from universal->.ex and .ex->universal?!?!? would it???
It would definitely be feasible to write a bytecode translator. I've been
playing around with that approach. But it's harder than is sounds, because
you still have to implement the sequence engine and bytecode interpreter to
deal with the Mac's quirky memory management scheme.
Generating a Java .class file is another option. Writing a sequence engine
is the hardest part, although I think that sequences can be roughly be
mapped to arrays. The main appeal of this approach is that Java is already
ported to lots of different machines. If you were really gung-ho, you could
generate a .java file (Java bytecodes) directly... 
-- David Cuny
5. Re: mac.exe
-------------------------------------------------------------
side note: new keyword--UniEU=Universal Euphoria
pronounced-- "you-nee-you"
Euphoria bytecode definitions
--------------------------------------------------------
David Cuny wrote:
> Hawke wrote:
>>if you write
>>a program that is truly ANSI C and then recompiled
>>that program on another platform, it should work, no?
> In the case of memory allocation, the answer is no.
ok, my C is real rusty (i hope to keep it that way:)
but my understanding is that getmem() and free()
were routines written such that when you compiled
on another platform, the functions were written differently
internally to grab/release memory without you having
to worry about things like we're discussing.
i'm almost *certain* that as i was at univ, learning
how to know enuff to be dangerous, that i routinely
wrote programs that i would compile depending upon
my current physical location. if it was noon lunch,
i'd be in a lab, floppy in hand, working on a specific
program and using a linux box. if it was bout 5pm,
i'd be in the mainframe room, working (ie:income),
and also doing 'homework' (namely said program) and
using the VAX (ALPHA processor) C compiler, on the
same program, and i would then go home and
(still same floppy, the vax & linuxbox could
read dos floppies)
work on that program on my PC djgpp compiler...
complete crossplatform compiling, and i used
get/free rather often, and of course a couple different
make files had to be made at the beginning...
so, i'm not sure about what your answer here means...
clarify?
>>now of course, with all it's extreme optimization,
>>Euphoria wouldn't recompile cross-platform
>We're not talking about extreme optimization here, but the
>basic mechanism used to implement sequences (pointers) and
>opcodes (function pointers).
well.... *ponder*... not sure about this, but isn't there a
generic pointer type inherent to ALL c? *pThis is *pThis
is *pThis no matter what compiler u use... it's the
compilers job to take the platform specific issues *away*
from the coder, by rewriting it's libraries for each platform.
(or was that ^pThis... hrm, get my c and pascal
confus-el-ed sumtimes)
lastly, i'd swear i heard a professor tell me that the reason
pointers were created was because they were to be used by
programmers needing platform*independence*. that no matter
what platform you were using, you were simply getting a variable
that automatically held a valid memory address of a particular
variable/constant/value you wanted to 'point' to. you declare
a pointer by declaring the type of data that the variable
your going to point to is holding. you don't declare it as
a variable that's going to hold a memory address ("well do
I need a word,DBLword,64bit,128bit etc" NOT!), the compiler does
that part for you. am i wrong about this?
>it's harder than is sounds, because you still have to
>implement the sequence engine and bytecode interpreter to
>deal with the Mac's quirky memory management scheme.
all right, given, you have to do funky, platform specific
wildchildrodehard things to get sequences to run (i mean
truly *run* like EU, not canter or prance, but
holdontoyourshoehorn gallop)...
but, I say lets get something truly universal working...
let's hammer out the opcode definitions, and the translators
and not worry about making the runtime engines yet...
let's not worry about which side of the car we're gonna
put the steering wheel on... the runtime engines are IMHO
like -last- on the list...
also, we can make a *generic* runtime engine, something
that can compile under any compiler, if we adhere to
*generic* routines. it'll be slower than EU, yes,
but IMHO, UniEU is the best of the potential suggestions
i've seen thus far as to how to get EU to the masses.
>Writing a sequence engine is the hardest part, although
>I think that sequences can be roughly be mapped to arrays.
sure, def'nly, !easy. But, all C compilers i know
of surely do support arrays, and i can almost envision
the pseudocode needed to make arrays behave like
sequences, at least for 'generic' runtime engines.
almost, not quite tho...
another thing, why do we have to talk C?
i can think of *several* languages that have some good
'generic' routines/data types, that are multi-platformed.
pascal for starters. another thing is that we (EU community)
don't have to give out the code used to make the runtime
engines, only the exe compiled for the platform.
>Generating a Java .class file is another option.
>The main appeal of this approach is that Java is already
>ported to lots of different machines.
not a bad thing. but does it have to be (as it sounds)
an either/or choice? why not UniEU translators -and-
EU->java & java->EU translators???
(assigned to 2 different teams, of course; after all,
would you want anyone fooling around with java near you? ;)
i see UniEU as potentially being 'better' than java anyway.
furthermore, i think it'd be harder to implement EU within
java as compared to other languages, but i haven't given
that particular point all that much thought.
>If you were really gung-ho, you could generate
>a .java file (Java bytecodes) directly...
or..... not. ;>
*12.4% of 0.50 unnamed currency units float slowly to the ground*
--Hawke'
6. Re: mac.exe
<snip snip longish stuff about macs, pointers and handles)
I have to agree with Hawke on this one David... a C compiler on the mac
should handle pointers just as if it were on DOS/WIN/UNIX/C64 whatever.
The low level implementation of a memory address may be different, but the
compiler will take care of all the memory locking/paging and offer the
normal C programmming fashions. I'm going back to college next week and I
will compile PEU on a Mac just to prove it can be done.
Java bytecode translation - now that's an interesting idea. Might have to
give this one some thought, and dig through some java docs.
[discard]
Anyone ever tried to throw away a sequence using an if statement? Let me
forewarn ya - it ain't gonna make ex.exe happy. A discard procedure would
be a welcome addition to the language... for now
procedure discard(object o) end procedure
will have to do.... and we'll just have to put up with the warning
messages unless they're turned off.
I can also see how Ralf's suggestion for discarding would work in the
interpreter. For PEU, simply have the discard procedure pop off and free
the last object on the stack. No type_checking, boolean test or possible
code jump would be performed. In a tight loop you might see a difference.
Laters,
_______ ______ _______ ______
[ _ \[ _ ][ _ _ ][ _ ]
[/| [_] |[/| [_\][/ | | \][/| [_\]
| ___/ | _] | | | _]
[\| [/] [\| [_/] [\| |/] [\| [_/]
[_____] [______] [_____] [______]
xseal at harborside.com ICQ:13466657
http://www.harborside.com/home/x/xseal/euphoria/
7. Re: mac.exe
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BDE678.EC318818
charset="iso-8859-1"
Pete wrote:
> I have to agree with Hawke on this one David... a C compiler
> on the mac should handle pointers just as if it were on
> DOS/WIN/UNIX/C64 whatever.
I'll be quite happy to be proven wrong here - I'll be able to start using it
on the Mac.
> Java bytecode translation - now that's an interesting idea. Might
> have to give this one some thought, and dig through some java docs.
Let me know how that turns out!
-- David Cuny
------_=_NextPart_001_01BDE678.EC318818
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>RE: mac.exe</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Pete wrote:</FONT>
</P>
<P><FONT SIZE=2>> I have to agree with Hawke on this one David... a C
compiler </FONT>
<BR><FONT SIZE=2>> on the mac should handle pointers just as if it were on
</FONT>
<BR><FONT SIZE=2>> DOS/WIN/UNIX/C64 whatever.</FONT>
</P>
<P><FONT SIZE=2>I'll be quite happy to be proven wrong here - I'll be able to
start using it on the Mac.</FONT>
</P>
<P><FONT SIZE=2>> Java bytecode translation - now that's an interesting
idea. Might </FONT>
<BR><FONT SIZE=2>> have to give this one some thought, and dig through some
java docs.</FONT>
</P>
<P><FONT SIZE=2>Let me know how that turns out!</FONT>
</P>
<P><FONT SIZE=2>-- David Cuny</FONT>
</P>
</HTML>
------_=_NextPart_001_01BDE678.EC318818--
8. Re: mac.exe
I don't like Macintoshes, and I have never programmed one, but I have been
developing a port of my Euphoria Pre-Processor for Java. Once in Java, it
could be used to run Euphoria programs on any platform that supports Java.
It wouldn't support any of the Win32 stuff since that is only on Win32
platforms, but it would support everything in the DOS version.
I have also been looking into developing a Java class file reader/writer to
translate Java to Euphoria and visa-versa, but it seems much harder, and I
haven't gotten far with it. At least I have my Euphoria version of my
pre-processor to base the Java version on.
Jeffrey Fielding
JJProg at cyberbury.net
9. Re: mac.exe
You know, I kinda started this debate here, but I think I'm a little in over
my head about the whole thing. I'll tell you what tho, if anyone comes up
with anything compiled, send me the address of where to download it, I'll send
that to my brother (who owns the Mac in question) and I'm sure he'd be willing
to Alpha/Beta/Eat it with Relish test it. He's only programmed in Pascal -- 4
years ago and poorly at that-- and I think he's really getting discouraged
trying to learn C. Especially since I can do things so easily in Euphoria.
thanks in advance,
snortboy
10. Re: mac.exe
- Posted by Matt Z Nunyabidness <matt1421 at JUNO.COM>
Sep 22, 1998
-
Last edited Sep 23, 1998
whats being an alpha tester?
-------------------------------------
When it comes to programming languages, Euphoria is a cut above -
matt1278 at juno.com and matt1421 at juno.com(and soon to be
irisnmatt at prodigy.net. Then again, maybe not) Euphoria programmer
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
11. Re: mac.exe
>whats being an alpha tester?
WHen developping a big or complicated program, it usually consists of
multiple parts, some less dificult than others. Fox example, when Robert
wrote ex.exe he would prolly started with a basic preproccesor, which he
tested until he knew for sure, it did what it did. Then I assume he wrote
the sequence engine.. same testing here.. then some of the built-in
routines, some testing, then the machine proc/functions (graphics, and
stuff) and finally the euphoria includes.
All these part were only a small subset of functionality of the complete
program, and alpha version are more to test if an approach (right?) will
work... then when found the right approaches/techniques for those problems
that seem to be the most complicated, then you combine most of it until some
form of program. Now we call it a Beta version. We test, test.. hope not to
find any too crucial problems, (so we have to rewrite a whole section) ..
this is the place where we usually put a few hacks in it, if we did make a
mistake in our original design. ("just make it work" - ideology) and we keep
calling it beta versions until we cant find any new error, and when the
crucial and simple errors are overcome, then we release it and call it the
complete version. (however, some Companies call alpha versions -- beta
versions and beta versions -- complete version, and use the audience to
test their software, for example, companies like MS and Borland are pretty
good at this. A lot of game designers as well.)
Ralf
12. Re: mac.exe
Ralf Nieuwenhuijsen wrote:
{someone asked (matt??)}
>>whats being an alpha tester?
ralf's answer is good.
mine is:
Being an alpha tester requires the innate need of
watching your computer reboot more than once every
ten minutes. Not just a desire, a need. You're
world should revolve around watching the bios
perform memory checking. You're very being should
be defined by the number of times per hour that
you see "Press <DEL> to enter setup". If you
have experience in Beta Testing, but felt that
the software under test was far too stable for
your personal CPS (crash per second) ratios
to be upheld, we are looking for you. Buy
this game from us, for a mere ~60$ U.S., and
you can feel the thrill of watching ScanDisk
report lost clusters for weeks on end.
Buy Now!
[The following was a paid advertisement for
Bugthesda Software, makers of BuggerFall
and it's sequel BugtleSpire.]
13. Re: mac.exe
Jeffrey Fielding wrote:
> developing a port of my Euphoria Pre-Processor for Java.
SNIP
>also a class file reader/writer to translate Java to Euphoria
>and visa-versa, but it seems much harder, and I
SNIP
you go!
*hands out morale and support snippets*
--Hawke'
14. Re: mac.exe
- Posted by Kevin Sieger <simkin at ZEBRA.NET>
Sep 23, 1998
-
Last edited Sep 24, 1998
Hawke wrote:
> Jeffrey Fielding wrote:
> > developing a port of my Euphoria Pre-Processor for Java.
> SNIP
> >also a class file reader/writer to translate Java to Euphoria
> >and visa-versa, but it seems much harder, and I
> SNIP
>
> you go!
>
> *hands out morale and support snippets*
>
> --Hawke'
Hmmm, the interesting thing here is that Java is supposedly slower than
Euphoria already, so programming a Euphoria interpreter in Java would be
like towing a Mercedes with A Ford Escort, would it not? IOW, perhaps
it would be a useful learning tool, but I think it might be too slow to
go anywhere serious.
Kevin
15. Re: mac.exe
Kevin Sieger wrote:
>so programming a Euphoria interpreter in Java would be
>like towing a Mercedes with A Ford Escort, would it not?
*snicker*
>perhaps it would be a useful learning tool, but I think
>it might be too slow to go anywhere serious.
well, it depends you know?
certain java apps/applets are not really involved
in real time activities. how fast some apps
run just isn't important in some cases...
like a java program that converts text into
pretty colors and saves the text and coloring
to html... java programs that create menus and
lists and dropdowns and forms and the like, they
aren't that speed critical... what would be nice
is that we could use EU to make these kinda programs
and those programs would then run on a large variety
of platforms. even puzzle games, card games, and
some multiplayer (turnbased) games could be done
and coded faster and easier with EU and still return
decent execution times.
it just depends on how the EU->java translation is
done. if its a java program that is running and
actively interpreting EU on the fly, that would likely
be bad. if its a java program that converts .ex to
java code (class files) then you might have something...
--Hawke'
16. Re: mac.exe
>Hmmm, the interesting thing here is that Java is supposedly slower than
>Euphoria already, so programming a Euphoria interpreter in Java would be
>like towing a Mercedes with A Ford Escort, would it not? IOW, perhaps
>it would be a useful learning tool, but I think it might be too slow to
>go anywhere serious.
Now stuff is going to get messy. Sorry, Robert to break your marketing
strategy, but Java is *not* nessecarily slower than Euphoria.
There are 2 reasons why it was times 8 times slower than Euphoria:
1) Benchmarks and common use have little to do with each other. Robert got
to choose the benchmark.
2) The Java Interpreter used was not of the new JIT technology. Which loads
slower, and more memory troubling, however it executes *faster* .. I repeat
.. *faster*
However, again, Java is not Euphoria and speed is not easily compared. For
example compare ASM and C++ using Watcom for example. ASM *in theory* and
*in benchmarks* runs much faster, however when coding a complicated program,
no human is capable of applying the same optimization as a smart compiler
could. That is why most programs are written in C, where some small crucial
parts where brainstormed about what the fastest possible code would be in
ASM and then that code was inlined.
Same goes for Euphoria. Many simpel safe tasks in Euphoria, take loads of
work and run slowly in Java. Simply because the tools dont fit the goal. A
screwdriver gives you more option than a hammer, however jamming nails in
with a screwdriver is still harder than using a hammer. That is again what
you call a *compromise*.. enough anology now.. 
Ralf
17. Re: mac.exe
Is your last name pronounced dkjgn8signng or nieoovenhayezen
-------------------------------------
When it comes to programming languages, Euphoria is a cut above -
matt1278 at juno.com and matt1421 at juno.com(and soon to be
irisnmatt at prodigy.net. Then again, maybe not) Euphoria programmer
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
