1. First ever IRC meeting has finished

A log can be found at:

http://jeremy.cowgar.com/euphoria/meeting1.html

I will work a bit later on formatting the log better. It was productive and
enjoyable. I hope the next time we have one, more people can join.

After a break to go outside and enjoy the fresh air, I will create a summary of
what we talked about and what the IRC group thought about various subjects
discussed.

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » topic index » view message » categorize

2. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> A log can be found at:
> 
> <a
> href="http://jeremy.cowgar.com/euphoria/meeting1.html">http://jeremy.cowgar.com/euphoria/meeting1.html</a>
> 
> I will work a bit later on formatting the log better. It was productive and
> enjoyable. I hope the next time we have one, more people can join.
> 
> After a break to go outside and enjoy the fresh air, I will create a summary
> of what we talked about and what the IRC group thought about various subjects
> discussed.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

I downloaded MIRC and they wanted money (Paypal).

I'm dead set against spending any money at this time with the economy the way it
is.

Don Cole

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

3. Re: First ever IRC meeting has finished

don cole wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > A log can be found at:
> > 
> > <a
> > href="http://jeremy.cowgar.com/euphoria/meeting1.html">http://jeremy.cowgar.com/euphoria/meeting1.html</a>
> > 
> > I will work a bit later on formatting the log better. It was productive and
> > enjoyable. I hope the next time we have one, more people can join.
> > 
> > After a break to go outside and enjoy the fresh air, I will create a summary
> > of what we talked about and what the IRC group thought about various
> > subjects
> > discussed.
> > 
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
> 
> I downloaded MIRC and they wanted money (Paypal).
> 
> I'm dead set against spending any money at this time with the economy the way
> it is.
> 
> Don Cole

Use Gaim.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

4. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> A log can be found at:
> 
> http://jeremy.cowgar.com/euphoria/meeting1.html
> 

Skimmed through the log.  Sorry I couldn't make it.  The weather was nice,
the grass long, and She Who Must Be Obeyed had me working outside all day...

I'll have more to say once you've written the summary.

Matt

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

5. Re: First ever IRC meeting has finished

Matt Lewis wrote:
> 
> Skimmed through the log.

Matt, I think some jokester must've put comments in there and attributed them
to someone else. heheh. heh. *gulp*

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

6. Re: First ever IRC meeting has finished

don cole wrote:
> 
> I downloaded MIRC and they wanted money (Paypal).

No, they didn't. Maybe for a donation, but you get it free for 30 days or
somesuch.

However, we found two free web-based clients:

www.mibbit.com

and the one on the RDS web site.

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

7. Re: First ever IRC meeting has finished

Updated log: 

http://jeremy.cowgar.com/euphoria/meeting1.html

Same as previous, just a *little* easier to read...

Summary of subjects talked about:

==== Namespace keyword addition
-- greeter.e
namespace greeter
global function say_hello()
  puts(1, "Hello!\n")
end function


-- myprog.e
include greeter.e -- notice no "as greeter"
greeter:say_hello()


-- myprogb.e
include greeter.e as g
g:say_hello()


Seems most people were not in favor of this stating that the programmer using
the library should have total control over if the include should have a namespace
or not.

==== Namespace delimiter a : or . ???

Most were in favor of . stating it's easier to read and type. Further that
namespaces would be used much more frequently in new releases as they were in the
past, starting with the standard library.

For those thinking that it is confusing because of OO languages, you must note
that most that use . as a delimiter in OO also use the same . as a namespace (or
package, depending on language) delimiter. For instance:

java.lang.String   and also  myStr.func()

==== New slice operator ~

Most were not in favor of this stating no need for additional complexity. head()
and tail() would do the same with more clarity as to what is actually being
performed.

==== File extensions

The idea was that we had too many file extensions. We have .e for include, .eu,
.ew for includes, .ex for DOS files, .exw for GUI windows, .exu for Unix
regardless if they are console or GUI. We have no extension for a Windows console
program (not same as a DOS program, for instance, a console program that made use
of wrapping DLLS such as sockets, or PCRE, or...). We also have no extension for
programs that will work on Windows and Linux/FreeBSD.

The group couldn't come to a consensus as to what should be done, it was tabled
for the Forums.

==== Versioning

It was close as to release new expanded library version as 3.2 or 4.0. 4.0
barely won. It was also close as to if we should release current bug fixes only
as 3.1.2. Releasing a bug fix version before any new changes barely won.

==== Prefix new grouped functions

A grouped function would be such as the datetime functions. They all deal with a
common theme/type. Should they be prefixed with datetime_, dt_, etc... or should
we rely on namespaces.

Relying on namespaces won. Thus, the programmer has control of any "prefix"

include datetime.e as d
d:now()

-- or
include datetime.e as datetime
datetime:now()


==== Hardware DEP

It was explained that it's not a matter as if we want Hardware DEP in the
Windows version, it's a matter of we have to have it. Currently it is an option
in XP and Vista and future versions of Windows will have it enabled by default.
The side effect is that Euphoria callbacks, as they exist now, are treated as
"non-executable" code, thus, Windows will not execute them. Your program will
fail.

With the Hardware DEP patch, when creating a callback, it is marked as
executable and with the more secure option in XP, Vista and future Windows
versions, Euphoria will work as expected.

------------

There was other misc talk through out the meeting, but the above were the major
topics touched.

Thank you for all who were involved.

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

8. Re: First ever IRC meeting has finished

c.k.lester wrote:
>
>
> posted by: c.k.lester <euphoric at ckle?ter.?om>
>
> don cole wrote:
>   
>> I downloaded MIRC and they wanted money (Paypal).
>>     
>
> No, they didn't. Maybe for a donation, but you get it free for 30 days or
> somesuch.
>
> However, we found two free web-based clients:
>
> www.mibbit.com
>
> and the one on the RDS web site.
>
>
>
>
Try Xchat at www.silverex.org its foss so have fun

-^Cricket^

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

9. Re: First ever IRC meeting has finished

> On 26 Apr 2008 at 18:16, don cole wrote (maybe snipped):

> I downloaded MIRC and they wanted money (Paypal).
> 
> I'm dead set against spending any money at this time with the economy
> the way it is.
> 
Don, I'm using Miranda IM (http://www.miranda-im.org/). It's free, 
open source, and covers all major protocols through plugins. 
Currently, I use mine to reach Yahoo, MSN, ICQ and Gmail (Jabber). I 
don't do IRC often but I only had to mark a checkbox yesterday to 
chat with the Eu-gang. Well, I had a small problem because I'm using 
an Alpha version (0.8.0 build 13 Unicode) and IRC.dll didn't work as 
expected. So I picked up the IRC DLL from last stable version and it 
made through.

Best,
Euler

-- 
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!

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

10. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> Updated log: 
> 
> <a
> href="http://jeremy.cowgar.com/euphoria/meeting1.html">http://jeremy.cowgar.com/euphoria/meeting1.html</a>
> 
> Same as previous, just a *little* easier to read...
> 
> Summary of subjects talked about:
> 
> 
> Seems most people were not in favor of this stating that the programmer
> using the library should have total control over if the include should
> have a namespace or not.

Can't get to the logs right now, but there seemed to be some confusion in
the discussion about how namespaces work.  If there is a namespace attached
to a file, you can use it or not.  The only time you have to use it is if
you reference a symbol which is ambiguous (i.e., you've included multiple 
files that declare a global with the same name). So:

==== Namespace keyword addition
-- greeter.e
namespace greeter
global function say_hello()
  puts(1, "Hello!\n")
end function

-- myprog.e
include greeter.e -- notice no "as greeter"
greeter:say_hello()
say_hello()         -- works the same


Matt

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

11. Re: First ever IRC meeting has finished

Matt Lewis wrote:
> 
> > Updated log: 
> > http://jeremy.cowgar.com/euphoria/meeting1.html
> 
> Can't get to the logs right now, 

Sorry, it's fixed.

> but there seemed to be some confusion in
> the discussion about how namespaces work.  If there is a namespace attached
> to a file, you can use it or not.  The only time you have to use it is if
> you reference a symbol which is ambiguous (i.e., you've included multiple 
> files that declare a global with the same name). So:
> 
> ==== Namespace keyword addition
> -- greeter.e
> }}}
<eucode>
> namespace greeter
> global function say_hello()
>   puts(1, "Hello!\n")
> end function
> </eucode>
{{{

> -- myprog.e
> }}}
<eucode>
> include greeter.e -- notice no "as greeter"
> greeter:say_hello()
> say_hello()         -- works the same
> </eucode>
{{{


If this is the case, then I am in strong favor of the new namespace keyword. Is
adding the namespace keyword a hard task? I'd like to use it in the standard
library right now, specifically with datetime and map. I am sure other uses will
come up as well with the standard library.

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

12. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> Updated log: 
> 
> <a
> href="http://jeremy.cowgar.com/euphoria/meeting1.html">http://jeremy.cowgar.com/euphoria/meeting1.html</a>
> 

Unfortunately, I wasn't there for most of the weekend.

> Same as previous, just a *little* easier to read...
> 
> Summary of subjects talked about:
> 
> ==== Namespace keyword addition
> -- greeter.e
> }}}
<eucode>
> namespace greeter
> global function say_hello()
>   puts(1, "Hello!\n")
> end function
> </eucode>
{{{

> 
> -- myprog.e
> }}}
<eucode>
> include greeter.e -- notice no "as greeter"
> greeter:say_hello()
> </eucode>
{{{

> 
> -- myprogb.e
> }}}
<eucode>
> include greeter.e as g
> g:say_hello()
> </eucode>
{{{

> 
> Seems most people were not in favor of this stating that the programmer using
> the library should have total control over if the include should have a
> namespace
> or not.
> 

I'd certainly prefer an actual implementation of packages, like the one a
description of which is posted at http://oedoc.free.fr/Packages.htm . However,
this is a first attempt at having this sort of functionality, so I'd support it.

> ==== Namespace delimiter a : or . ???
> 
> Most were in favor of . stating it's easier to read and type. Further that
> namespaces
> would be used much more frequently in new releases as they were in the past,
> starting with the standard library.
> 
> For those thinking that it is confusing because of OO languages, you must note
> that most that use . as a delimiter in OO also use the same . as a namespace
> (or package, depending on language) delimiter. For instance:
> 
> java.lang.String   and also  myStr.func()
> 

No opinion here.

> ==== New slice operator ~
> 
> Most were not in favor of this stating no need for additional complexity.
> head()
> and tail() would do the same with more clarity as to what is actually being
> performed.
> 

And most importantly mid() or equal_slice() see needed, see my post about
Equals().

> ==== File extensions
> 
> The idea was that we had too many file extensions. We have .e for include,
> .eu,
> .ew for includes, .ex for DOS files, .exw for GUI windows, .exu for Unix
> regardless
> if they are console or GUI. We have no extension for a Windows console program
> (not same as a DOS program, for instance, a console program that made use of
> wrapping DLLS such as sockets, or PCRE, or...). We also have no extension for
> programs that will work on Windows and Linux/FreeBSD.
> 
> The group couldn't come to a consensus as to what should be done, it was
> tabled
> for the Forums.

How about .exc for console programs, since they usually can run on both DOS and
unices? I think that's the only missing one.

> 
> ==== Versioning
> 
> It was close as to release new expanded library version as 3.2 or 4.0. 4.0
> barely
> won. It was also close as to if we should release current bug fixes only as
> 3.1.2. Releasing a bug fix version before any new changes barely won.
> 

Voting for 4.0 as well, with perhape an alpha and a beta before official
release. And a massive call for testers.

> ==== Prefix new grouped functions
> 
> A grouped function would be such as the datetime functions. They all deal with
> a common theme/type. Should they be prefixed with datetime_, dt_, etc... or
> should we rely on namespaces.
> 
> Relying on namespaces won. Thus, the programmer has control of any "prefix"
> 
> }}}
<eucode>
> include datetime.e as d
> d:now()
> 
> -- or
> include datetime.e as datetime
> datetime:now()
> </eucode>
{{{

> 

Probably cleaner.

> ==== Hardware DEP
> 
> It was explained that it's not a matter as if we want Hardware DEP in the
> Windows
> version, it's a matter of we have to have it. Currently it is an option in XP
> and Vista and future versions of Windows will have it enabled by default. The
> side effect is that Euphoria callbacks, as they exist now, are treated as
> "non-executable"
> code, thus, Windows will not execute them. Your program will fail.
> 
> With the Hardware DEP patch, when creating a callback, it is marked as
> executable
> and with the more secure option in XP, Vista and future Windows versions,
> Euphoria
> will work as expected.
> 

Good.

CChris

> ------------
> 
> There was other misc talk through out the meeting, but the above were the
> major
> topics touched.
> 
> Thank you for all who were involved.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

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

13. Re: First ever IRC meeting has finished

CChris wrote:
> 
> And most importantly mid() or equal_slice() see needed, see my post about
> Equals().

Yes, in the standard library is: head(), mid(), tail() among others. You can see
some of the new functions by just viewing svn:

http://rapideuphoria.svn.sourceforge.net/svnroot/rapideuphoria/trunk/include

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

14. Re: First ever IRC meeting has finished

I think too much smoke and not much heat and light was expended with regards to
extensions. I vote to leave things as it is, with a couple of caveats:

1) .e and .ex should be considered either generic or DOS and it should be
documented which is applicable as per whatever program. Or platform tested within
the file itself.

2) There should be an option of downloading either an installer or a raw zip
file for the current Euphoria release.

3) For the Windows installer, there should be an option whether the ex.exe or
exwc.exe is associated with .ex files.

4) Or the DOS interpreter should be an optional or separate install altogether.
Still part of the official release but not necessarily installed at the same time
as the Windows interpreter. The *nix package (.deb or .tgz) shouldn't have to
worry about it.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

15. Re: First ever IRC meeting has finished

Jason Gade wrote:
> 
> I think too much smoke and not much heat and light was expended with regards
> to extensions. I vote to leave things as it is, with a couple of caveats:
> 
> 1) .e and .ex should be considered either generic or DOS and it should be
> documented which is applicable as per whatever program. Or platform tested
> within the file itself.

I'm having a hard time getting worked up about this.  This is only an issue
for setting associations on Windows.  If you're a developer, I can't manage
any sympathy if this is too high a hurdle.  If you're distributing code, then
you shouldn't be relying on file associations.  Either distribute bound or
translated code, or provide a .bat file.

> 2) There should be an option of downloading either an installer or a raw
> zip file for the current Euphoria release.

Yes.  They will at least be up on sourceforge.  We just have to get Rob
to agree to put a link on rapideuphoria.com.

Matt

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

16. Re: First ever IRC meeting has finished

Matt Lewis wrote:
> 
> Jason Gade wrote:
> > 
> > I think too much smoke and not much heat and light was expended with regards
> > to extensions. I vote to leave things as it is, with a couple of caveats:
> > 
> > 1) .e and .ex should be considered either generic or DOS and it should be
> > documented which is applicable as per whatever program. Or platform tested
> > within the file itself.
> 
> I'm having a hard time getting worked up about this.  This is only an issue
> for setting associations on Windows.  If you're a developer, I can't manage
> any sympathy if this is too high a hurdle.  If you're distributing code, then
> you shouldn't be relying on file associations.  Either distribute bound or
> translated code, or provide a .bat file.

Sure it's easily fixed, but why not just distribute it correctly? I understand
that it's the install of Euphoria that sets up the associations. Why do it wrong?

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

17. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> Matt Lewis wrote:
> > 
> > I'm having a hard time getting worked up about this.  This is only an issue
> > for setting associations on Windows.  If you're a developer, I can't manage
> > any sympathy if this is too high a hurdle.  If you're distributing code,
> > then
> > you shouldn't be relying on file associations.  Either distribute bound or
> > translated code, or provide a .bat file.
> 
> Sure it's easily fixed, but why not just distribute it correctly? I
> understand that it's the install of Euphoria that sets up the associations.
> Why do it wrong?

It's not clear to me what's wrong and what's right.

Matt

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

18. Re: First ever IRC meeting has finished

Matt Lewis wrote: 
> I'm having a hard time getting worked up about this.  This is only an issue
> for setting associations on Windows.  If you're a developer, I can't manage
> any sympathy if this is too high a hurdle.  If you're distributing code, then
> you shouldn't be relying on file associations.  Either distribute bound or
> translated code, or provide a .bat file.
> Matt

Which is the point that I was trying to make, put more succinctly thank you.

If you are distributing platform-dependent code, then put in a call to
platform() somewhere.

Related, it might be nice to add a version() built-in, or piggy-back it with
platform(), eventually.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

19. Re: First ever IRC meeting has finished

Jason Gade wrote:
> 
> Which is the point that I was trying to make, put more succinctly thank you.
> 
> If you are distributing platform-dependent code, then put in a call to
> platform()
> somewhere.

The problem is not the code not looking for a platform, it's the platform not
using the right exe to execute the code because the associations are installed
wrong via the Euphoria installer.

I think the right thing to do is:

.e, .ew, .eu are all valid includes
.ex = link to ex.exe
.exw = link to exw.exe
.exc = link to exwc.exe

I really think it's that easy. No voodoo involved.

.exw = any platform, windowed.
.exc = any platform, console.
.ex = dos

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

20. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > Which is the point that I was trying to make, put more succinctly thank you.
> > 
> > If you are distributing platform-dependent code, then put in a call to
> > platform()
> > somewhere.
> 
> The problem is not the code not looking for a platform, it's the platform not
> using the right exe to execute the code because the associations are installed
> wrong via the Euphoria installer.

Right, which Matt pointed out was a problem really only affecting Windows.

> 
> I think the right thing to do is:
> 
> .e, .ew, .eu are all valid includes
> .ex = link to ex.exe
> .exw = link to exw.exe
> .exc = link to exwc.exe
> 
> I really think it's that easy. No voodoo involved.
> 
> .exw = any platform, windowed.
> .exc = any platform, console.
> .ex = dos
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

.exw = Windows specific
.ex = generic or DOS specific
.exu = *nix specific

Platform specific code should have platform() checks. The Windows installer
should associate .ex files with exwc.exe, unless the user has specifically
installed the DOS version of the interpreter.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

21. Re: First ever IRC meeting has finished

Jason Gade wrote:
> 
> .exw = Windows specific
> .ex = generic or DOS specific
> .exu = *nix specific

You left out files that are cross platform. What about an app that works equally
as well on Windows, Linux and FreeBSD? That's the main problem here. Euphoria is
a cross-platform language and more apps are being made that are cross-platform.

.ex = DOS
.exc = Any console app (regardless, if for Windows/Linux/FreeBSD)
.exw = Any windowed (or GUI) app (regardless if for Windows/Linux/FreeBSD).

.exc and .exw files should do their own platform() checks.

.ex should be kept linked to ex.exe for backward compatibility.

What is wrong with the above?

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

22. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > .exw = Windows specific
> > .ex = generic or DOS specific
> > .exu = *nix specific
> 
> You left out files that are cross platform. What about an app that works
> equally
> as well on Windows, Linux and FreeBSD? That's the main problem here. 

No I didn't -- use .ex for cross platform apps. Cross platform == generic.

> Euphoria
> is a cross-platform language and more apps are being made that are
> cross-platform.
> 
> .ex = DOS
> .exc = Any console app (regardless, if for Windows/Linux/FreeBSD)
> .exw = Any windowed (or GUI) app (regardless if for Windows/Linux/FreeBSD).
> 
> .exc and .exw files should do their own platform() checks.
> 
> .ex should be kept linked to ex.exe for backward compatibility.
> 
> What is wrong with the above?

Nothing, except that it is more complicated than the status quo and my own
proposal. Euphoria doesn't need a different program extension for every
combination of OS and console/gui application type and whether a given file is an
include or an executable.

Let's not regress twenty-plus years here.

> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>


--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

23. Re: First ever IRC meeting has finished

Jason Gade wrote:
> 
> Nothing, except that it is more complicated than the status quo and my own
> proposal.
> Euphoria doesn't need a different program extension for every combination of
> OS and console/gui application type and whether a given file is an include or
> an executable.
> 
> Let's not regress twenty-plus years here.

But you said that .ex will link to the DOS interpreter, therefore, it's not
cross platform?

Maybe before we go down this route further, what does ex.exe do that exwc.exe
does not? Anything?

My point on IRC was that the file extensions are way to numerous. For instance,
ruby, python, lua... they do not have different extensions for every platform
they run on. And that's further agervated by the current scheme that we have no
true cross-platform extension.

So... Is it possible to do everything that ex.exe does with exwc.exe? Therefore,
linking .ex to run Dos, Windows and Linux apps would work just fine if .ex was
run by exwc.exe?

Therefore, no need for exu or exw even.

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

24. Re: First ever IRC meeting has finished

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > Nothing, except that it is more complicated than the status quo and my own
> > proposal.
> > Euphoria doesn't need a different program extension for every combination of
> > OS and console/gui application type and whether a given file is an include
> > or
> > an executable.
> > 
> > Let's not regress twenty-plus years here.
> 
> But you said that .ex will link to the DOS interpreter, therefore, it's not
> cross platform? 

What I meant was that for some users .ex will link to the DOS interpreter. It
will be a user choice, and optimally most users won't even install the DOS
interpreter.

> 
> Maybe before we go down this route further, what does ex.exe do that exwc.exe
> does not? Anything?

Well, DOS graphics is the only real thing that comes to mind. Certain
assumptions regarding machine access and memory model. For text-only? Not so much
I think, however I'm sure I'll be corrected if wrong.

> 
> My point on IRC was that the file extensions are way to numerous. For
> instance,
> ruby, python, lua... they do not have different extensions for every platform
> they run on. And that's further agervated by the current scheme that we have
> no true cross-platform extension.
> 

The point with which I am trying to agree with you. Ideally, Euphoria program
extensions should be as generic as a file ending in ".py" or ".pl" or ".htm" or
".html".

> So... Is it possible to do everything that ex.exe does with exwc.exe?
> Therefore,
> linking .ex to run Dos, Windows and Linux apps would work just fine if .ex was
> run by exwc.exe?
> 
> Therefore, no need for exu or exw even.

I think that exwc (and exu) can do most of the things that ex.exe can do. The
main differences are direct access to graphics and sound and maybe certain
assumptions with regards to memory allocation. Of course, the documentation (both
within and outside of the source) should indicate whether a piece of code is
platform-specific or not.

> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>


--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

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

25. Re: First ever IRC meeting has finished

Matt Lewis wrote:
> 
> Jason Gade wrote:
> > 
> > 1) .e and .ex should be considered either generic or DOS and it should be
> > documented which is applicable as per whatever program. Or platform tested
> > within the file itself.
> 
> I'm having a hard time getting worked up about this.  This is only an issue
> for setting associations on Windows.  If you're a developer, I can't manage
> any sympathy if this is too high a hurdle.  If you're distributing code, then
> you shouldn't be relying on file associations.  Either distribute bound or
> translated code, or provide a .bat file.

Actually, I would suggest that the minimum should be bound and packaged with
something like NSIS.

Mike

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

26. Re: First ever IRC meeting has finished

> On 27 Apr 2008 at 19:10, Jeremy Cowgar wrote (maybe snipped):

> posted by: Jeremy Cowgar <jeremy at cowgar.c??>
> 
> Jason Gade wrote:
> > 
> > Nothing, except that it is more complicated than the status quo and
> > my own proposal. Euphoria doesn't need a different program extension
> > for every combination of OS and console/gui application type and
> > whether a given file is an include or an executable.
> > 
> > Let's not regress twenty-plus years here.
> 
> But you said that .ex will link to the DOS interpreter, therefore,
> it's not cross platform? 
> 
> Maybe before we go down this route further, what does ex.exe do that
> exwc.exe does not? Anything?
> 
> My point on IRC was that the file extensions are way to numerous. For
> instance, ruby, python, lua... they do not have different extensions
> for every platform they run on. And that's further agervated by the
> current scheme that we have no true cross-platform extension.
> 
> So... Is it possible to do everything that ex.exe does with exwc.exe?
> Therefore, linking .ex to run Dos, Windows and Linux apps would work
> just fine if .ex was run by exwc.exe?
> 
> Therefore, no need for exu or exw even.
> 
Jeremy and others,

Extension is a Windows (DOS) thing. It's how the OS relates actions 
to files. If I got the right idea from Rob Craig (in Refman), 
Euphoria is totally independent from extensions. You can run .e, .ex, 
.exw, .exu, .nothing, whatever, in any OS. So, running the code is 
not a problem. BUT, if you want to run-on-click (e.g. on Windows), 
set an icon, etc., you'll need to make the proper action attribution 
to a proper extension.

Once I built an installer package for Euphoria that put things just 
like the following:

 Ext | Description         | Dbl-click   | Icon (3)  | Comments
-----+---------------------+-------------+-----------+---------------
.e   | Eu DOS32 library    | ed.bat %1   | greyscale |
.ex  | Eu DOS32 executable | exwc.exe %1 | colourful | ex.exe (1) 
.ew  | Eu Win32 library    | ed.bat %1   | greyscale |
.exw | Eu Win32 executable | exw.exe %1  | colourful |
.eu  | Eu Unix library     | ed.bat %1   | greyscale |
.exu | Eu Unix executable  | ed.bat %1   | greyscale | ex/exw.exe (2)
=====================================================================

(1) My choice of exwc.exe instead of ex.exe is just because it was 
    planned to run *under* Windows, not DOS. Installers are ALSO a 
    Windows thing, IMHO. ;)

(2) I thought I shouldn't run a Linux program under Windows, but this 
    shouldn't prevent me to edit them. So, both .eu and .exu will invoke 
    the editor.

(3) A greyscale Euphoria icon was used to point the libraries, while 
    a colorful icon to executable code. As said already, this is just a 
    convention, nothing is mandatory, but it's somewhat essential if you 
    will do things in an environment like Windows.

While I don't care if extensions will/should be deprecated or 
extended I'll continue do things the same way, that is:

Libraries
---------
.e  Generic code that can be used on any (or more than one) platform;
.ew Windows specific library. Can't be used on any other platform, 
    otherwise use .e;
.eu Linux/FreeBSD specific library. Can't be used on any other 
    platform, otherwise use .e;

Executables
-----------
.ex Generic executable that can be used on any (or more than one) 
    platform, e.g. DOS32 (ex.exe), or Windows console (exwc.exe), or 
    Linux/FreeBSD console (exu.exe);
.exwWindows specific executable. Can't be run on any other platform, 
    otherwise use .ex;
.exuLinux/FreeBSD specific executable. Can't be run on any other 
    platform, otherwise use .ex.

Just to clarify, if you write a piece of code to run on a website 
hosted in a FreeBSD server that could also run on a Windows server, 
use something like MyCode.ex, otherwise use MyCode.exu (or MyCode.exw 
contrariwise).

Better stop now. I tend to nonsense when I *talk* too much. ;)

Best,
Euler

-- 
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
_| -----------------------------
_| Reply preferably to the list,
_| or to the address above. Thx!

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

27. Re: First ever IRC meeting has finished

Euler German wrote:
> 
> 
> Extension is a Windows (DOS) thing. It's how the OS relates actions 
> to files. If I got the right idea from Rob Craig (in Refman), 
> Euphoria is totally independent from extensions. You can run .e, .ex, 
> .exw, .exu, .nothing, whatever, in any OS. So, running the code is 
> not a problem. BUT, if you want to run-on-click (e.g. on Windows), 
> set an icon, etc., you'll need to make the proper action attribution 
> to a proper extension.

Yes, it is a Windows thing, but when you install Euphoria on Windows, the
installer sets the associations. Now, to further complicate things, it sets .ex
to run as ex.exe. The demos in euphoria/demos are .ex... While in Vista, I double
click a .ex, and a dialog appears that says "This OS does not support DOS mode."
and gives me the option to Close or Ignore. Sometimes Ignoring will work, other
times the app is requesting full screen, which also is not supported under Vista.

> 
> (2) I thought I shouldn't run a Linux program under Windows, but this 
>     shouldn't prevent me to edit them. So, both .eu and .exu will invoke 
>     the editor.

Why not? say I build a program that converts a text file to an HTML file. That
will run in DOS, Windows and Unix. It's neither a DOS, nor a Windows nor a Unix
program, it's a cross-platform application.
 
> (3) A greyscale Euphoria icon was used to point the libraries, while 
>     a colorful icon to executable code. As said already, this is just a 
>     convention, nothing is mandatory, but it's somewhat essential if you 
>     will do things in an environment like Windows.
> 
> While I don't care if extensions will/should be deprecated or 
> extended I'll continue do things the same way, that is:
> 
> Libraries
> ---------
> .e  Generic code that can be used on any (or more than one) platform;
> .ew Windows specific library. Can't be used on any other platform, 
>     otherwise use .e;
> .eu Linux/FreeBSD specific library. Can't be used on any other 
>     platform, otherwise use .e;

And what about includes that work on any platform except DOS, which there are a
lot of those due to DOS not being able to link in .DLL files.

> Executables
> -----------
> .ex Generic executable that can be used on any (or more than one) 
>     platform, e.g. DOS32 (ex.exe), or Windows console (exwc.exe), or 
>     Linux/FreeBSD console (exu.exe);
> .exwWindows specific executable. Can't be run on any other platform, 
>     otherwise use .ex;
> .exuLinux/FreeBSD specific executable. Can't be run on any other 
>     platform, otherwise use .ex.

And, what about those growing number of applications who do not care where they
are run? I vote .ex, as you do, however, that's not valid as .ex is linked on
Windows to ex.exe by the Euphoria installer. Therefore, most Windows/Linux
applications will not function on Windows with the extension of .ex.

--
Jeremy Cowgar
http://jeremy.cowgar.com

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

Search



Quick Links

User menu

Not signed in.

Misc Menu