1. non-x86 development
hey, i have an idea. as long as euphoria PD source is being sold, why
not try development for other platforms or architectures? 68k and old
PowerPC Macintoshes are cheap and easy to find on eBay(i bought a
Centris 610 and monitor on eBay for $45 total, but then i got the
speakers from a linux box that couldn't use em ;). with a certain level
of coding knowlege, it could be recoded to work on a mac, and you
wouldn't have to give up standard functions like fopen() either. the Mac
standard C library has just about all of them. but before you start
looking at me...i'm just beginning and i can't even open a movable
window in the MacOS, but SIOW would probably be a suitable alternative
for a console(besides the fact it's just plain text w/o colors)
2. Re: non-x86 development
> hey, i have an idea. as long as euphoria PD source is being sold, why
> not try development for other platforms or architectures? 68k and old
> PowerPC Macintoshes are cheap and easy to find on eBay(i bought a
> Centris 610 and monitor on eBay for $45 total, but then i got the
> speakers from a linux box that couldn't use em ;).
Before I got this PC, I've worked on Mac a lot (we've got three Macs at
home)
I am not sure if coding for 68k architecture is a good idea. AFAIK, 68k is
now
not supported by Apple. (The new OSes requirre at least G3). It is problem
to port Eu to another Unix, so porting it to Mac would be a big problem.
Translating the Eu code to other architecture would be difficult, because
some
parts of code are in ASM, and there are differences between the OSes -
MacOS <9 have no STDIN / STDOUT - so you have to emulate console.
And you will have to add all this Mac specific code to libraries - calling
ROM routines
(QuickDraw), calling OS, working with resources etc.
> with a certain level
> of coding knowlege, it could be recoded to work on a mac, and you
> wouldn't have to give up standard functions like fopen() either. the Mac
> standard C library has just about all of them. but before you start
> looking at me...i'm just beginning and i can't even open a movable
> window in the MacOS, but SIOW would probably be a suitable alternative
> for a console(besides the fact it's just plain text w/o colors)
I looked at few pieces of code, and MacOS API seems more complicated to
me than WIN32 API. You will have to read the Mac Programming Bible. (very
fat book)
You may get to run some currnet generic Eu progs, (after modifications like
using
':' instead of '\\', but creating GUI apps would be dfficult.
I wouldn't do this. It requires a lot work.
Matin
3. Re: non-x86 development
martin stachon wrote:
> I am not sure if coding for 68k architecture
> is a good idea. AFAIK, 68k is now not supported
> by Apple. (The new OSes require at least G3).
DOS isn't supported by Microsoft anymore, but I don't know that it's been a
serious deterrent to Euphoria.
> It is problem to port Eu to another Unix, so
> porting it to Mac would be a big problem.
I was under the impression that there were only two bits of
architecture-specific code in Euphoria:
1. Bits encoding the type are endian-specific.
2. Numbers are assumed to be 32 bits.
I would think that could be isolated with some #ifdefs. I would assume that
Robert uses sizeof() and other standard coding practices to insulate his
code.
> Translating the Eu code to other architecture
> would be difficult, because some parts of code
> are in ASM,
Are they? Even if Euphoria generates in-line assembly, you could still add
flags to suppress these optimizations on non x86 platforms. And we know that
Robert's had to port Euphoria to several compilers, so the code isn't
specific to a single compiler's features.
> and there are differences between the OSes -
> MacOS <9 have no STDIN / STDOUT - so you have
> to emulate console.
These are automatically provided by most Mac C libraries. You end up getting
something that looks like a DOS console on a 68K Mac pretty much for free
using Metrwerks, for example.
> And you will have to add all this Mac specific code
> to libraries - calling ROM routines (QuickDraw), calling
> OS, working with resources etc.
You have to do native calls under Linux and Windows as well.
> I looked at few pieces of code, and MacOS
> API seems more complicated to me than WIN32
> API. You will have to read the Mac Programming
> Bible. (very fat book)
I don't think the Mac API is *that* much more complicated than Windows.
> You may get to run some current generic
> Eu progs, (after modifications like using
> ':' instead of '\\', but creating GUI apps
> would be difficult.
No more difficult than on other platforms.
> I wouldn't do this. It requires a lot work.
I wouldn't make that assumption until seeing Robert's source. You could be
right, but at this point, it's all speculation. When I get my copy, I hope
to give it a whirl on an emulated 68K Mac.
-- David Cuny
4. Re: non-x86 development
sephiroth wrote:
> when you decide to emulate a mac, just ask if
> you need anything. i've got a coupla large disk
> images(system software, downloads, MPW for
> programming, etc...), though i think i may have
> oversized the second one, but bzip2 should be
> able to handle it considering it's mostly empty
I've used the vMac images with good success. Is you've got MPW, you should
probably be able to compile Euphoria the source yourself. It's a very UNIX-y
environment, although way obsolete now. It's nice that Apple finally decided
to release it free a couple years back.
I picked up an older version of the MetroWerks compiler on eBay for around
$20. It'll build 68K or fat Mac binaries. But I'm always struggling for free
disk space, so I'll wait for the Euphoria code before reinstalling it.
Thanks.
-- David Cuny
5. Re: non-x86 development
David Cuny wrote:
> martin stachon wrote:
>
> > I am not sure if coding for 68k architecture
> > is a good idea. AFAIK, 68k is now not supported
> > by Apple. (The new OSes require at least G3).
> DOS isn't supported by Microsoft anymore, but I don't know that it's been
a
> serious deterrent to Euphoria.
I don't know much about MacOS low-level stuff.
(I've been programming on Mac only with HyperTalk,
nice language, something like VisualBasic, only one datatype,
you can freely insert 'a' , 'an', 'the' into code, = can be written as 'is'
etc...,
AppleScript is based on its syntax.), but I think the API
for MacOS <=9 is different than for MacOS X.
So you will have to write two versions of Eu for Mac.
It is possible to create programs with dual code (FAT) - 68k and PowerPC.
(With two CODE resources)
> > It is problem to port Eu to another Unix, so
> > porting it to Mac would be a big problem.
>
> I was under the impression that there were only two bits of
> architecture-specific code in Euphoria:
>
> 1. Bits encoding the type are endian-specific.
> 2. Numbers are assumed to be 32 bits.
What about some built-in routines - getenv, command_line.
> I would think that could be isolated with some #ifdefs. I would assume
that
> Robert uses sizeof() and other standard coding practices to insulate his
> code.
>
> > Translating the Eu code to other architecture
> > would be difficult, because some parts of code
> > are in ASM,
>
> Are they? Even if Euphoria generates in-line assembly, you could still add
> flags to suppress these optimizations on non x86 platforms. And we know
that
> Robert's had to port Euphoria to several compilers, so the code isn't
> specific to a single compiler's features.
>
> > and there are differences between the OSes -
> > MacOS <9 have no STDIN / STDOUT - so you have
> > to emulate console.
>
> These are automatically provided by most Mac C libraries. You end up
getting
> something that looks like a DOS console on a 68K Mac pretty much for free
> using Metrwerks, for example.
>
> > And you will have to add all this Mac specific code
> > to libraries - calling ROM routines (QuickDraw), calling
> > OS, working with resources etc.
>
> You have to do native calls under Linux and Windows as well.
>
> > I looked at few pieces of code, and MacOS
> > API seems more complicated to me than WIN32
> > API. You will have to read the Mac Programming
> > Bible. (very fat book)
>
> I don't think the Mac API is *that* much more complicated than Windows.
>
> > You may get to run some current generic
> > Eu progs, (after modifications like using
> > ':' instead of '\\', but creating GUI apps
> > would be difficult.
>
> No more difficult than on other platforms.
>
> > I wouldn't do this. It requires a lot work.
>
> I wouldn't make that assumption until seeing Robert's source. You could be
> right, but at this point, it's all speculation. When I get my copy, I hope
> to give it a whirl on an emulated 68K Mac.
>
> -- David Cuny
I don't know if Mac programmers would be interested.
They are used with C and beginners with AppleScript.
Eu for Mac would be isolated from other Eu world,
because you could run only some generic command-line apps,
(I don't know how would be emulated passing parameters via command line?)
And I am not sure if Mac users like console.
Very little libraries and programs would be for it.
(Like Eu for Linux - it has only four contributions in RUC)
But who knows ?
sephirot writes:
> when you decide to emulate a mac, just ask if you need anything. i've
> got a coupla large disk images(system software, downloads, MPW for
> programming, etc...), though i think i may have oversized the second
> one, but bzip2 should be able to handle it considering it's mostly empty
I would help you too (I have a 68000, 68030 and PowerPC 603 machine)
I am a fan of Mac. Especially I would like to see MacOS X, it combines
Unix with great GUI). But I had to move to PC because of cheaper
HW, more SW etc.
Martin Stachon
6. Re: non-x86 development
- Posted by euman at bellsouth.net
Jul 22, 2001
That one other must be me, and if anyone wants it let me know.
Unless Pete wants to re-open his Euphoria website.
I have the last version Menno patched together.
30 dec 2000 that will run most of the examples from
David Cuny's win32lib ver .45
Menno never released this version.
I also have the last that Pete worked on before Menno started
helping out and most of the updates Menno and Pete together
mapped out.
Why I held on to these, I dont know.......... :)
Euman
euman at bellsouth.net
----- Original Message -----
From: "sephiroth _" <euman2376 at yahoo.com>
To: "EUforum" <EUforum at topica.com>
Sent: Sunday, July 22, 2001 21:24
Subject: RE: non-x86 development
>
>
> i suppose it would work, but then it wouldn't be a real mac port
>
> > Isn't there a MS WINDOWS emulator for the MAC so you could use EXW?
>
> > I think that pete eberlein had a euphoria clone running on
> > BEE maybe when the source is available you could look at pete's
> > source and use it as a guide to write a port.
>
> i think a few of us here on the list(at the moment, me, david cuny, and
> one other) have pete's source
>
>
>
>
7. Re: non-x86 development
- Posted by munchr at mac.com
Jul 22, 2001
At 10:54 PM 7/22/2001 -0500, Euman wrote:
Actually, the December2k/January2k1 version was released from Menno on
Pete's Euphoria Zone on Jan 2, 2001 with updated files from Dec. 30, Dec. 31,
and Jan. 1.
Coincidently, that was the last update made to his page, which is still up and
active.
James Powell
>
>Unless Pete wants to re-open his Euphoria website.
>
>I have the last version Menno patched together.
>30 dec 2000 that will run most of the examples from
>David Cuny's win32lib ver .45
>
>Menno never released this version.
>
>I also have the last that Pete worked on before Menno started
>helping out and most of the updates Menno and Pete together
>mapped out.
>
>Why I held on to these, I dont know.......... :)
>
>
>Euman
>euman at bellsouth.net
>
>
>
>----- Original Message -----
>From: "sephiroth _" <euman2376 at yahoo.com>
>To: "EUforum" <EUforum at topica.com>
>Sent: Sunday, July 22, 2001 21:24
>Subject: RE: non-x86 development
>
>
> >
> >
> > i suppose it would work, but then it wouldn't be a real mac port
> >
> > > Isn't there a MS WINDOWS emulator for the MAC so you could use EXW?
> >
> > > I think that pete eberlein had a euphoria clone running on
> > > BEE maybe when the source is available you could look at pete's
> > > source and use it as a guide to write a port.
> >
> > i think a few of us here on the list(at the moment, me, david cuny, and
> > one other) have pete's source
> >
> >
> >
> >
8. Re: non-x86 development
- Posted by jbrown105 at hotpop.com
Jul 23, 2001
On 0, euman at bellsouth.net wrote:
>
>
> That one other must be me, and if anyone wants it let me know.
>
> Unless Pete wants to re-open his Euphoria website.
>
> I have the last version Menno patched together.
> 30 dec 2000 that will run most of the examples from
> David Cuny's win32lib ver .45
>
> Menno never released this version.
>
> I also have the last that Pete worked on before Menno started
> helping out and most of the updates Menno and Pete together
> mapped out.
>
> Why I held on to these, I dont know.......... :)
>
>
> Euman
> euman at bellsouth.net
>
I tried compiling Meno's version under linux, but after getting 25 screens of
errors, I found it works only for dos & windows. Do you have a version
(very recent, that is) that works for Linux? I have one that does, but it
is very old.
jbrown105
>
>
> ----- Original Message -----
> From: "sephiroth _" <euman2376 at yahoo.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, July 22, 2001 21:24
> Subject: RE: non-x86 development
>
>
> >
> >
> > i suppose it would work, but then it wouldn't be a real mac port
> >
> > > Isn't there a MS WINDOWS emulator for the MAC so you could use EXW?
> >
> > > I think that pete eberlein had a euphoria clone running on
> > > BEE maybe when the source is available you could look at pete's
> > > source and use it as a guide to write a port.
> >
> > i think a few of us here on the list(at the moment, me, david cuny, and
> > one other) have pete's source
> >
> >
> >
> >
>
>
>
>
--
Linux User:190064
Linux Machine:84163
http://jbrown105.1avenue.com
9. Re: non-x86 development
sephirot wrote:
> martin.stachon at worldonline.cz wrote:
> actually, there's the standard CODE resource for 68k programs, and then
> PowerPC code is contained in the data fork. that's why you get an error
> running a PPC program with no 68k code(no CODE resource)
It is a long a time since I have been 'hacking' programs with ResEdit, but
under Mac there is no code in data fork. Most programs have data fork empty.
(The resource fork is a great thing. All program data is contained in
program, sorted by type, and easy editable)
I suppose there is small 68k code which decides if run 68k or PPC version
CODE.
>
> > What about some built-in routines - getenv, command_line.
>
> > Eu for Mac would be isolated from other Eu world,
> > because you could run only some generic command-line apps,
> > (I don't know how would be emulated passing parameters via command
> > line?)
>
> ah, you're forgetting MacOS X's UNIX-side. you can simply open a
> terminal and call Eu like "exu hello", of course it'd be kind of
> pointless because it wouldn't be Mac-specific, just PPC UNIX-specific.
Only for G3 and better.
> > I would help you too (I have a 68000, 68030 and PowerPC 603 machine)
>
> PPC 603? i made a mistake and got a Centris 610. doesn't even have an
> FPU :)
It s possible to upgrade some 68k machines to PPC.
Regards,
Martin
