1. Euphoria feature request
I wish for a procedure include( filename ) that would work the same as the
current way to include files. This way in my editor I'm making, I can have
a subdirectory (in the directory with the editor in it) called extentions,
it will have an include file for each file extention the end-user wants to
be able to edit. I would need have a include procedure to do this because I
do not know if the user downloaded support for only 2 extentions or 50
extentions.
One alternative I could do would be to run dir() on the extentions
directory, get the list of files to include, have my editor make a file
called includes.e, write include statements for all those files to include,
then include includes.e. But if I did that, I wouldn't be able to bind it
because I would be making euphoria code. Maybe I could just keep a copy of
the eu source code in a sequence in the executable file, and when I wrote
the includes.e file, I could make my .exw source file for the editor then
re-bind it, delete all the source files, then delete the editor that is
running, start the newly made editor, maybe I could just do it silently so
the user wouldn't notice.
What do you think I should do about it?
Thanks,
Phil
2. Re: Euphoria feature request
I think you're confusing binding with translating.
When you bind a file, you're basically throwing Euphoria code onto the end
of the PDE (Public Domain Edition) Interpreter. The interpreter then looks
for the code at the end of the file and begins to execute it. Of course,
it's not that simple, there are certain things it looks for so you can't
just toss your code onto the end of your interpreter and have a working .exe
file.
When you translate a file, your Euphoria code is interpreted into C code,
then compiled by your choice of compiler. At no point is the source of the
interpreter included in this process. The C code produced by the Translator
may have some of the same routines and macros in order to emulate the
behavior of the Interpreter, such as error handling and sequence
manipulation, but it's still C.
If you're looking for a way to build modules of Euphoria code, you have a
few options:
1 Use EuScript by Matt Lewis. you can run Euphoria code within a Euphoria
program, as plain text, but speed may become an issue since Euphoria does
not support threads, which would speed up execution. This is not for complex
code.
2. Build DLL files with the Translator. This, however, would require
users to each have a translator. A standard naming convention would also
need to be in place. This is how many other software developers handle
extentions or modules, but I'm sure you'd like to keep everything in Eu
code, not C executables.
3. I recently bought a copy of the source, and I'm looking into
converting the interpreter into a DLL file similar to EuScript. This would
make life a lot easier for most of us. I'll keep everone updated on my
progress.
~Greg
> I wish for a procedure include( filename ) that would work the same as the
> current way to include files. This way in my editor I'm making, I can
have
> a subdirectory (in the directory with the editor in it) called extentions,
> it will have an include file for each file extention the end-user wants to
> be able to edit. I would need have a include procedure to do this because
I
> do not know if the user downloaded support for only 2 extentions or 50
> extentions.
>
>
> One alternative I could do would be to run dir() on the extentions
> directory, get the list of files to include, have my editor make a file
> called includes.e, write include statements for all those files to
include,
> then include includes.e. But if I did that, I wouldn't be able to bind it
> because I would be making euphoria code. Maybe I could just keep a copy
of
> the eu source code in a sequence in the executable file, and when I wrote
> the includes.e file, I could make my .exw source file for the editor then
> re-bind it, delete all the source files, then delete the editor that is
> running, start the newly made editor, maybe I could just do it silently so
> the user wouldn't notice.
>
> What do you think I should do about it?
>
> Thanks,
> Phil
3. Re: Euphoria feature request
I had not heard of EuScript before, I'll check it out.
I had considered DLLs, but I don't know how to make them. I tried running
ecw on a .ew file then running emake, and I got a .exe, not a .dll
How can I make DLLs with the translator?
Phil
-----
Greg Haberek said:
I think you're confusing binding with translating.
When you bind a file, you're basically throwing Euphoria code onto the end
of the PDE (Public Domain Edition) Interpreter. The interpreter then looks
for the code at the end of the file and begins to execute it. Of course,
it's not that simple, there are certain things it looks for so you can't
just toss your code onto the end of your interpreter and have a working .exe
file.
When you translate a file, your Euphoria code is interpreted into C code,
then compiled by your choice of compiler. At no point is the source of the
interpreter included in this process. The C code produced by the Translator
may have some of the same routines and macros in order to emulate the
behavior of the Interpreter, such as error handling and sequence
manipulation, but it's still C.
If you're looking for a way to build modules of Euphoria code, you have a
few options:
1 Use EuScript by Matt Lewis. you can run Euphoria code within a Euphoria
program, as plain text, but speed may become an issue since Euphoria does
not support threads, which would speed up execution. This is not for complex
code.
2. Build DLL files with the Translator. This, however, would require
users to each have a translator. A standard naming convention would also
need to be in place. This is how many other software developers handle
extentions or modules, but I'm sure you'd like to keep everything in Eu
code, not C executables.
3. I recently bought a copy of the source, and I'm looking into
converting the interpreter into a DLL file similar to EuScript. This would
make life a lot easier for most of us. I'll keep everone updated on my
progress.
~Greg
> I wish for a procedure include( filename ) that would work the same as
the
> current way to include files. This way in my editor I'm making, I can
have
> a subdirectory (in the directory with the editor in it) called
extentions,
> it will have an include file for each file extention the end-user wants
to
> be able to edit. I would need have a include procedure to do this
because
I
> do not know if the user downloaded support for only 2 extentions or 50
> extentions.
>
>
> One alternative I could do would be to run dir() on the extentions
> directory, get the list of files to include, have my editor make a file
> called includes.e, write include statements for all those files to
include,
> then include includes.e. But if I did that, I wouldn't be able to bind
it
> because I would be making euphoria code. Maybe I could just keep a copy
of
> the eu source code in a sequence in the executable file, and when I wrote
> the includes.e file, I could make my .exw source file for the editor then
> re-bind it, delete all the source files, then delete the editor that is
> running, start the newly made editor, maybe I could just do it silently
so
> the user wouldn't notice.
>
> What do you think I should do about it?
>
> Thanks,
> Phil
TOPICA - Start your own email discussion group. FREE!
4. Re: Euphoria feature request
On Tue, 09 Dec 2003 15:36:23 -0500, "Philip D."
<philip1987 at hotmail.com> wrote:
>I wish for a procedure include( filename ) that would work the same as the
>current way to include files. This way in my editor I'm making, I can have
>a subdirectory (in the directory with the editor in it) called extentions,
>it will have an include file for each file extention the end-user wants to
>be able to edit.
As I understand this query, you are planning to release an editor
which will allow different user-defined code to cope with the
different filename extensions.
1) you need to define an API that such code can use.
2) binding/translating is not possible, however you slice it.
2a) distributing a program which can perform bind is strictly
against Rob's licence. (PD Interpreter+shrouded would be OK)
Step back a bit, and state what you want to do, instead of explaining
a potential solution you are having problems with.
Regards,
Pete
http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
5. Re: Euphoria feature request
<snip>
Step back a bit, and state what you want to do, instead of explaining
a potential solution you are having problems with.
Regards,
Pete
http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
-----
Ok, I'll try to state what I want, like you said. I want to make an editor
which, when it opens a file, it reads the files extention and allows for
different editing for each file type. I could have an editor for .exw files
when I opened a .exw, or for .pdf files when I opened a .pdf (I'll try to
add support for a lot of extentions.)
When it will open a file, it looks in a folder called extentions to see if
the support file is there for the extention of the file. If it is not, it
will open the file into a text editor and a hex editor ( probably on 2
different tabs ). If it is supported ( the user downloaded my support file
for the editor ), then I'll probably call a routine named openFile( filename
), then the support file for that extention will create all the controls
for editing that file (in the tab that the editor gave for the file). The
support file should take care of all events necessary to edit the program
plus have specific routines ( like openFile, newFile, saveFile, printFile )
which are called when certain buttons are pushed on the toolbar in the main
editor ( or menuitems clicked ).
I don't know how to include all the support files when I do not know ahead
of time which files are there, and I don't know how to call the common
routines ( such as openFile ) that would be present in every support file (
because there will be namespace problems ).
Thanks,
Phil
www16.brinkster.com/philip1987/euphoria
P.S. Sorry about what I said about the binder, I didn't realize I couldn't
do that. I don't have a binder anyway. Someday I'll register probably.
6. Re: Euphoria feature request
On 9 Dec 2003, at 17:18, Greg Haberek wrote:
>
>
> I think you're confusing binding with translating.
>
> When you bind a file, you're basically throwing Euphoria code onto the end
> of the PDE (Public Domain Edition) Interpreter. The interpreter then looks
> for the code at the end of the file and begins to execute it. Of course,
> it's not that simple, there are certain things it looks for so you can't
> just toss your code onto the end of your interpreter and have a working .exe
> file.
>
> When you translate a file, your Euphoria code is interpreted into C code,
> then compiled by your choice of compiler. At no point is the source of the
> interpreter included in this process. The C code produced by the Translator
> may
> have some of the same routines and macros in order to emulate the behavior of
> the Interpreter, such as error handling and sequence manipulation, but it's
> still C.
>
> If you're looking for a way to build modules of Euphoria code, you have a
> few options:
>
> 1 Use EuScript by Matt Lewis. you can run Euphoria code within a Euphoria
> program, as plain text, but speed may become an issue since Euphoria does not
> support threads, which would speed up execution. This is not for complex code.
Use eval() in Bach, it's pretty darned fast. Karl made it, it works, but RDS is
against it.
Kat
7. Re: Euphoria feature request
Philip D. wrote:
> I had considered DLLs, but I don't know how to make them. I tried
> running ecw on a .ew file then running emake, and I got a .exe, not a .dll
>
> How can I make DLLs with the translator?
For Windows and Borland C use:
ecw -dll -bor yourfile.ew
For WATCOM C use -wat
See:
http://www.rapideuphoria.com/e2c.htm#dynamic
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Euphoria feature request
On Tue, 09 Dec 2003 19:31:14 -0500, "Philip D."
<philip1987 at hotmail.com> wrote:
>If it is supported ( the user downloaded my support file
>for the editor )
OK, that simplifies the problem loads.
>I don't know how to include all the support files when I do not know ahead
>of time which files are there, and I don't know how to call the common
>routines ( such as openFile ) that would be present in every support file (
>because there will be namespace problems ).
My solution would be to create a start-up file, eg:
editor.exw:
include editexw.e
include editpdf.e
include mainedit.e
<end of editor.exw>
That's it, three (or so) lines, so it is easy to delete/recreate such
a file as & when additional components are downloaded.
You cannot use namespaces, each common routine (eg openFile) has to be
uniquely named (eg openExwFile), but you can build the required string
and use routine_id (if it does not return -1) to call it, or (if it
does return -1) prompt to download the required component.
Hope that helps,
