1. fixed windows
- Posted by gertie at visionsix.com
Aug 05, 2003
So the mirc nicklist and channel window are just fixed (but changeable and
detachable) child windows in the parent ! That explains how it is possible to
move each channel out of the mirc application screen and out onto the
desktop. Just think where Eu would be now if RobC had merged Eu and mirc
functionality way back when i first suggested it. Eu would look like
Bach/Bliss/OpenEu/mIRC now. And beat the pants off everything out there.
Kat
2. Re: fixed windows
> Hey Kat,
>
> <big snip>
>
> > 2) goto
>
> Please no ! In my pov only hobby programmers need goto. That is
> why many pro languages don't have it. There is nothing I can do
> with goto that I can't already do without (but yes, you need to
> do some "engineering" before starting to program).
Uh-oh.
Travis Beaty
Osage, Iowa.
4. Re: fixed windows
Kat wrote:
<snip>
>>> Golly, really? Are you the only one who matters then? If Robc includes
>>> goto, you think throngs of mad programmers will descent on you next
>>> fullmoon and force you to re-write all your code with goto?
Obviously you enjoy it, telling us three times a week, that you really
like 'goto'. Well, why not, if it makes you fell better. But even if you
would tell us t.i.d., fortunately Rob will *not* include it.
>> Come on Kat, you behave like a little kid that doesn't get
>> her way of doing things.
>
> And the way some people argue against an OPTION like goto in Eu is
> bordering on pathological.
Oh, "Dr Kat" speaking ...
Please stop that nonsense.
TIA, Juergen
--
The difference between men and boys
is the price of their toys.
5. Re: fixed windows
On Tue, Aug 05, 2003 at 02:06:16PM -0500, gertie at visionsix.com wrote:
<snip>
> In a word(s):
>
> mirc:
First, mirc will not run in Linux, FreeBSD, or DOS. So such a merger between
Eu and mIRC would make Eu Windows-only. So a comparision between the 2 is
not really far in terms of portability. Also such a merger would be difficult
when using the translator. (If you say that you don't need these features of Eu,
then I have no choice but to call you a hypocrite, since you believe you
should have the below features even if others don't need them. I'm sure
there is a compromise to be found in there somewhere ;)
> 1) executing strings
Not builtin. DC and Matt Lewis have given us the option as an addon lib tho.
Cost: speed.
> 2) goto
Well, Dredge has that ...
Beyond that, I say no more ;[
> 3) threads (including threaded timers)
Have it (for linux).
Cost: speed and memory (and quite a bit of complexity). Also, with my
*emulation*, its not as fault-tolerant as real threads would be.
> 4) event handling
Have lots of libs for that.
Cost: speed, also no major lib so potentionally much confusion.
> 5) native socks support (you can http/telnet/pop3 with mirc too)
Why does it have to be native? Very few languages have it "native".
Cost: none that I can think of atm.
> 6) easy as heck gui support
At a high overhead. But it may be well worth the cost, depending on your
POV.
Cost: personally, i think the mirc way costs more.
> 7) no var instanciation required
> 8) no crash if a var has no contents in a boolean test
Dredge has these 2.
I think that Eu would do well to have these 2 options in it as well.
Cost: using Dredge gives a huge overhead, both in the compile stage
and in the run-time (due to the hacks required).
>
> Bach:
> 9) classes
Have lots of libs for that.
Would be nice if there was a simpler standard syntax for Euphorian OO tho
(as there will be for OE).
Cost: builtin would make the interp slower, external lib would make OO slower
+ lack of syntax (or use of preproc to get that) makes it clumsy to use.
If syntax were builtin, then I'd say the cost would be greater for OO to be
totally builtin into the interpreter (see OE notes on its proposed OO support
for a better explaination on what I mean).
> 10) crash catching
I have an errhandle.e that makes a meek attempt to provide this, but it has a
HUGE overhead ... this is a must.
Cost: using errhandle.e is too slow, and not using it means programs can't
have crash catching periond so they arent as robust.
> 11) gui support
Bach's GUI IMO isn't the best. Also, must GUI support be builtin?
Cost: I don't know enough to say.
> 12) block comments
A niceity but not a necessity.
Cost: more typing
> 13) slicing shorthands
Ditto.
Cost: more typing
> 14) better include paths
Yes, again a must.
Cost: possibly more typing, possibly much confusion for the programmer (on how
to get the right file to always be included).
<snip>
>
> Kat
>
jbrown
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
6. Re: fixed windows
On Tue, Aug 05, 2003 at 09:44:53PM +0000, Peter Willems wrote:
>
> So how did he manage to release the last update then ?
The later Eu updates add very little features. Once Euphorian once said that
they amount to bugfixes.
>
> > Mirc is hardly restricted to "a very (VERY) specific application area*.
> > Just
> > because it has one screen format for irc does not mean it cannot just as
> >
> > easily handle other tasks. What you are saying is like saying feet are
> > for
> > walking with, and if you have no feet, you cannot move at all. Or feet
> > should
> > not be used to play soccer with. Or hair should be worn the way you say,
> >
> > and worn any other way is confusing.
>
> I really don't see my company developing enterprise solutions
> with mIRC for our clients, but I can use Euphoria, Python,
> Erlang, Modula, Pascal, Oberon, etc. fine for that.
> These are all multi-purpose languages, mIRC is most certainly not.
Perhaps it could be. I won't know, being a linux user.
But yes mirc certainly wasn't designed with that intent.
>
> Hans Peter Willems
>
jbrown
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
7. Re: fixed windows
On Tue, Aug 05, 2003 at 10:34:57PM -0400, jbrown105 at speedymail.org wrote:
> Once Euphorian once said
Erm, Its "As one Euphorian once said".
jbrown
P.S. No that Euphorian wasn't me. Not originally, anyways.
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
8. Re: fixed windows
On Tue, Aug 05, 2003 at 08:03:39PM -0700, kbochert at copper.net wrote:
> > 3) threads (including threaded timers)
> Bach 2 does have coroutines which allow cooperative
> multitasking. Not quite the same thing, but its a start.
>
> Another feature which I have lately realized is quite
> doable is child processes:
> child_exec("foo.exe -w")
> would operate just like system_exec(), except that
> the child process would have its stdio redirected
> to the parent.
> Is this old hat?
> Is there a Eu library that does this?
For Linux there is. I don't know about Windoze.
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
9. Re: fixed windows
On Tue, Aug 05, 2003 at 07:51:43PM +0000, Peter Willems wrote:
Hey Kat,
gertie at visionsix.com wrote:
<big snip>
> 1) executing strings
You might need it, I don't.
Already have it.
> 2) goto
Please no ! In my pov only hobby programmers need goto. That is
why many pro languages don't have it. There is nothing I can do
with goto that I can't already do without (but yes, you need to
do some "engineering" before starting to program).
No comment.
> 3) threads (including threaded timers)
Agreed. Multi threading can help with several applications.
Nevertheless, the current tool we use in my company also don't
have multi-threading and still use it to develop for multi
nationals and to their satisfaction.
Don't have the real thing, have a pretty good emulation for Linux which is
portable to FreeBSD. Also portable to Windows via Cygwin (the cygwin dll
that is).
> 4) event handling
There is a full event-driven library in the archive.
So we alreayd have it.
> 5) native socks support (you can http/telnet/pop3 with mirc too)
I have no problem in it not being native. It's a library in most
other languages as well.
Concurred.
> 6) easy as heck gui support
Now here is where your comparison with mIRC goes completely wrong.
mIRC is a application with a userface that can be driven with it's
scripting language. That is com[pletely different from a language
that is USED to build that user interface (I already stated that
mIRC, including it's user interface, is not written in it's own
scripting language).
Let's be honest, there is no GUI developer in mIRC that generates
code that can then be executed without running mIRC's own FULL
user interface.
No comment.
> 7) no var instanciation required
No comment on that.
> 8) no crash if a var has no contents in a boolean test
Ditto..
> Bach:
> 9) classes
I'm glad Euphoria is NOT object oriented in it's own design.
It should be nicer for OO programs, but it also shouldnt impose an overhead
for non-OO programs. Hmm, this is tricky ... OE has a solution tho.
> 10) crash catching
Agreed. But that is not specific for mIRC OR Bach.
Bach and mIRC both have it tho. Eu doesn't.
> 11) gui support
Don't know what Bach has over Eu in this regard.
It is compiled with a GUI, so the GUI's routine's are available as
Bach builtin routines (i dont remember, was it called IUP?)
> 12) block comments
We're discussing that in depth already, so you know my view on
that. Seems I'm not alone on this point either.
> 13) slicing shorthands
No idea what that's about 
Basicly to make typing easier. Basicly the same idea behind block comments,
afai would use them.
> 14) better include paths
Clarify please ??
Search the mailing list. You'll see tons of stuff about namespaces, include
paths, include enchancements, etc. (I'd go into detail for you but I'm tired,
maybe if you email me privately I'll get back to you tomorrow.)
> These 14 items are things BobC has said will not appear in Eu. The
> closest
> app i have seen coded in Eu that might enable all the above is AGetz's
> window server and Jiri's associated lists. And several string libs are
> required
> in my opinion, string.e and strtok.e, and the file manipulation libs
> like file.e,,
> and for any windows gui, you must have win32lib.
That is your idea of how Eu should be developed, mine is different.
And other users might still have yet another pov. Don't forget
you are not the ONLY user.
But shes not the only one asking for this stuff either.
> If RobC can't handle the full developement of Eu,
.... the way YOU think he should do it.... right ?
And a great many others.
Kat, the bottom line is that I might (but shurely will) use Eu
for completely different tasks then you. And other people might
use it for yet completely different tasks. That is why Euphoria
is a GENERAL PURPOSE language while mIRC is a tool dedicated to
a very (VERY) specific application area.
Concurred, but what is being said is this: Many of us don't think
Eu is general enough!
Btw, Kat, have you aver heard of Erlang ? It's a language that
is developed by Ericson Telecom that seems to have everything
you desire in a language AND it is open source and completely
free. The proxy stuff you where asking for a while ago is easy
in Erlang as it has all that stuff build into the language.
You can get it at http://www.erlang.org
It's one of my choices for distributed tcp-based applications
and I'm going to make sure that my new IDE can handle Erlang as
well 
No comment.
Hans Peter Willems
TOPICA - Start your own email discussion group. FREE!
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
--
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: fixed windows
On Tue, Aug 05, 2003 at 04:02:17PM -0500, gertie at visionsix.com wrote:
On 5 Aug 2003, at 19:51, Peter Willems wrote:
>
>
> Hey Kat,
>
> gertie at visionsix.com wrote:
>
> <big snip>
>
> > 1) executing strings
>
> You might need it, I don't.
And you are saying since you don't need the option, i should be forced to do
without?
If he is saying that, I would say he is wrong.
> > 2) goto
>
> Please no ! In my pov only hobby programmers need goto. That is
> why many pro languages don't have it. There is nothing I can do
> with goto that I can't already do without (but yes, you need to
> do some "engineering" before starting to program).
Yes, stop thinking of the program and it's flow, and engineer a workaround
that the programming language will allow.
> > 3) threads (including threaded timers)
>
> Agreed. Multi threading can help with several applications.
> Nevertheless, the current tool we use in my company also don't
> have multi-threading and still use it to develop for multi
> nationals and to their satisfaction.
So again, you don't need it, so i can't have it.
Again, i would disagree with him then. (Just because he doesnt need it
doesnt mean it shouldnt be in there).
> > 4) event handling
>
> There is a full event-driven library in the archive.
Not quite what i wanted, i don't see it doing:
on error:*sequence lengths not equal*: { code here }
Thats not event handling, thats error catching.
> > 5) native socks support (you can http/telnet/pop3 with mirc too)
>
> I have no problem in it not being native. It's a library in most
> other languages as well.
Sure, Eu has such libs also, and every one has drawbacks. You can do x in
one, but not in the other, whch can do y.
Sounds like Eu just has more options.
> > 6) easy as heck gui support
>
> Now here is where your comparison with mIRC goes completely wrong.
> mIRC is a application with a userface that can be driven with it's
> scripting language. That is com[pletely different from a language
> that is USED to build that user interface (I already stated that
> mIRC, including it's user interface, is not written in it's own
> scripting language).
And you think Eu is written in Euphoria?
JTLYK, It can be: see eu.ex
Anyways, his point is explained futher below.
> Let's be honest, there is no GUI developer in mIRC that generates
> code that can then be executed without running mIRC's own FULL
> user interface.
Wrong. You can generate child windows that have their own button in the
taskbar, move independantly of the main mirc window, etc.. Besides, i
WANT the full language available to me to run the code i write. The display,
in any font i can download, in any point size, in any color, at any point, with
full mouse support, is a plus.
But you still need the whole of mirc loaded to do that. You can't get rid of
the main mirc window. I think thats the point being made.
> > 7) no var instanciation required
>
> No comment on that.
>
> > 8) no crash if a var has no contents in a boolean test
>
> Ditto..
By your previous tone, i suspect that means you are against them. So far,
you are against everything i suggest but threads. How unexpected.
> > Bach:
> > 9) classes
>
> I'm glad Euphoria is NOT object oriented in it's own design.
I don't actually like the way classes are in Bach, but it seems others do. I
want *full* variant records, with overriding.
> > 10) crash catching
>
> Agreed. But that is not specific for mIRC OR Bach.
It's possible to recover in mirc, to a point. For instance, i can type:
/msg cs addop nick 3
which is an error, and which i can script to correct before it finally errors
out.
Hey, I can write code to catch almost all runtime errors in Eu as well!
Just wrap every single builtin routine and do tons of checking and only call
the real builtin if everything looks ok, else abort out. (Note that errhandle.e
actually does this. It also provides routines to replace the builtin operators
and a function to wrap the tests in an if or elsif or while statement to prevent
crashing there.)
(It would be better for the support to be builtin no doubt, due to overhead,
but I'm just saying ... ;)
> > 11) gui support
>
> Don't know what Bach has over Eu in this regard.
Size. Open source, for nix and winders.
I wonder if IUP could be wrapped for normal Eu *shrug*.
> > 12) block comments
>
> We're discussing that in depth already, so you know my view on
> that. Seems I'm not alone on this point either.
>
> > 13) slicing shorthands
>
> No idea what that's about
I'm sure you won't like it, and will vote to keep it from me in Eu.
> > 14) better include paths
>
> Clarify please ??
Bach introduced looking in the application's own /include subdir, not just the
interpreter's /include subdir. And other places.
> > These 14 items are things BobC has said will not appear in Eu. The
> > closest
> > app i have seen coded in Eu that might enable all the above is AGetz's
> > window server and Jiri's associated lists. And several string libs are
> > required
> > in my opinion, string.e and strtok.e, and the file manipulation libs
> > like file.e,,
> > and for any windows gui, you must have win32lib.
>
> That is your idea of how Eu should be developed, mine is different.
> And other users might still have yet another pov. Don't forget
> you are not the ONLY user.
Golly, really? Are you the only one who matters then? If Robc includes goto,
you think throngs of mad programmers will descent on you next fullmoon and
force you to re-write all your code with goto?
No, tho he might be forced to deal with unreadable goto's in other's code.
The idea of not having goto support, is to replace it with better controlled
and restricted "goto"s which prevent the unreadablility. Whether or not this
is a good thing depends on the skill of the programmer, the level of difficulty
of the language overall (i.e. if its asm code then a goto or jmp isnt gonna
make it that much more unreadable), and personal opinion.
> > If RobC can't handle the full developement of Eu,
>
> .... the way YOU think he should do it.... right ?
It's already apparent he is out of time, whether i say anything or not. I think
you are a great example of the pot calling the kettle black.
LOL!
> Kat, the bottom line is that I might (but shurely will) use Eu
> for completely different tasks then you. And other people might
> use it for yet completely different tasks. That is why Euphoria
> is a GENERAL PURPOSE language while mIRC is a tool dedicated to
> a very (VERY) specific application area.
Mirc is hardly restricted to "a very (VERY) specific application area*. Just
because it has one screen format for irc does not mean it cannot just as
easily handle other tasks. What you are saying is like saying feet are for
walking with, and if you have no feet, you cannot move at all. Or feet should
not be used to play soccer with. Or hair should be worn the way you say,
and worn any other way is confusing.
Or perhaps hes just not as creative in using mirc as you are. IIRC, you said you
have done things w/ mirc that the creator didn't think was possible.
Kat
jbrown
TOPICA - Start your own email discussion group. FREE!
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
11. Re: fixed windows
----- Original Message -----
From: "Matt Lewis" <matthewwalkerlewis at yahoo.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: fixed windows
>
>
> kbochert at copper.net wrote:
>
> > I have always felt that a big part of Eu's popularity was its
> > low-level ability -- run on dos, write console apps, poke memory,
> > etc. Maybe not.
>
> I like the feeling that I can usually focus on an algorithm without
> having to fight the language (at least more so than with other languages
> I have tried). It largely has to do with the flexibility of the
> datatypes, but also the clean, clear syntax.
Wirth also developed Pascal because he felt that structured data was just as
important as structure programming. He'd hate Euphoria's dynamically typed data
structures. But I agree with you in that the fluid nature of Euphoria's datatypes
makes so many coding problems just disappear. It would be nice if we could have
both dynamically typed and statically typed data in the same language. There is a
place for both.
--
Derek
12. Re: fixed windows
Hi Matt, you wrote:
> kbochert at copper.net wrote:
>
>> I have always felt that a big part of Eu's popularity was its
>> low-level ability -- run on dos, write console apps, poke memory,
>> etc. Maybe not.
>
> I like the feeling that I can usually focus on an algorithm without
> having to fight the language (at least more so than with other languages
> I have tried). It largely has to do with the flexibility of the
> datatypes, but also the clean, clear syntax.
<snip>
That's exactly the same with me!
And apparently that's why Prof. Kuntz uses Euphoria in his courses at
the Mathematics Department of the Monmouth University (New Jersey):
http://mathserv.monmouth.edu/coursenotes/kuntz/kuntz.htm
BTW: What topic is exactly discussed under the subject
"fixed windows"?
Best regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | This message has been ROT-13 encrypted
X e-mail and news, | twice for higher security.
/ \ and unneeded MIME |
13. Re: fixed windows
Hi Derek, you wrote:
> ----- Original Message -----
> From: "Matt Lewis"
>
>> kbochert at copper.net wrote:
>>
>>> I have always felt that a big part of Eu's popularity was its
>>> low-level ability -- run on dos, write console apps, poke memory,
>>> etc. Maybe not.
>>
>> I like the feeling that I can usually focus on an algorithm without
>> having to fight the language (at least more so than with other languages
>> I have tried). It largely has to do with the flexibility of the
>> datatypes, but also the clean, clear syntax.
>
> Wirth also developed Pascal because he felt that structured data was
> just as important as structure programming. He'd hate Euphoria's
> dynamically typed data structures. But I agree with you in that the
> fluid nature of Euphoria's datatypes makes so many coding problems just
> disappear.
Interesting, that you say so! That's exactly the experience, that I made.
Formerly using Basic, I was often faced with problems, that I didn't
know how to solve. Now using Euphoria, several problems simply do not
appear at all. It's kind of magic for me.
> It would be nice if we could have both dynamically typed and
> statically typed data in the same language. There is a place for both.
I believe structures for instance are statically typed data, right?
IMHO such data types are especially important, when it comes to
communication with the rest of the programming world (read: programs
written in C).
Best regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | This message has been ROT-13 encrypted
X e-mail and news, | twice for higher security.
/ \ and unneeded MIME |
14. Re: fixed windows
- Posted by 1evan at sbcglobal.net
Aug 06, 2003
Peter Willems wrote:
>
>
>kbochert at copper.net wrote:
>
>
>>I think that Dijkstra has scared programmers enough that
>>they use goto verrry carefully.
>>
>>
> I'm curious how many people here on the list ever heard of him
>
>Hans Peter Willems
>
Oh, yeah. Bobby Dijkstra. Big bully. Used to beat up computer geeks
and take their lunch money. :)
