1. Standardisation between Win libraries
This is mainly aimed at those wonderful (and pretty darn clever) people
out there who develop the Windows libraries (win32Lib, eWin32API, etc)
for this great language.
Is it possible for you all to talk together and decide on a standard set
of include files for the definitions of Windows constants ie. for
WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
With one single set of includes it would make the use of Euphoria for
Windows soooo much easier. I currently use win32Lib for most Windows
apps, but have to use eWin32API for OpenGL stuff - both of which are
missing features the other has and would conflict (I'm sure) if I tried
to include both in the same application.
I know each of you, probably, prefer to think your version is the best -
most flexible, correct, enhancable, etc; but when developing apps (or
trying to!) I'm more into completeness - if the function ain't available
in a certain library, then it puts me off using it. Most of the
libraries simply wrap the standard DLL's anyway.
What I'm trying to say/ask is can you all develop for a single
Uber-Library, that gives the full flexibility and completeness without
redeveloping what each other is doing? Stick it in a single folder and
then everyone will know where to look for info.
My Euphoria folders are getting cluttered up with various windowing
libraries and it's starting to get clumsy to use.
Sorry in advance if this starts a bad discussion thread - it's not meant
as an attack on anyone, just trying to help organise things - a little!
--------------------------------------------------------
Blog about Euphoria at www.purpletiger.com/dave/blog.php
--------------------------------------------------------
2. Re: Standardisation between Win libraries
On Wed, 23 Jul 2003 20:18:05 +0000 (07/24/03 06:18:05)
, Dave Probert <zingo at purpletiger.com> wrote:
>
>
> This is mainly aimed at those wonderful (and pretty darn clever) people
> out there who develop the Windows libraries (win32Lib, eWin32API, etc)
> for this great language.
>
> Is it possible for you all to talk together and decide on a standard set
> of include files for the definitions of Windows constants ie. for
> WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
Sounds like a good idea. I suggest that the Microsoft standard be used.
That is, for each Microsoft supplied C header file (.h) that contains
constants for Windows code, we develop a similarly named .ew file for
Euphoria.
We can only define constants this way as Routine Headers are accessed
differently in win32lib compared to the other Windows Eu libraries (and I'm
not going to change it either). Now if only Euphoria didn't complain about
identically defined global constants...
However, one (small?) problem with this approach is that, unlike compiled
code, all the constants will be inserted into RAM by the Eu interpreter,
not just the ones actually used by your application.
> With one single set of includes it would make the use of Euphoria for
> Windows soooo much easier. I currently use win32Lib for most Windows
> apps, but have to use eWin32API for OpenGL stuff - both of which are
> missing features the other has and would conflict (I'm sure) if I tried
> to include both in the same application.
>
> I know each of you, probably, prefer to think your version is the best -
> most flexible, correct, enhancable, etc; but when developing apps (or
> trying to!) I'm more into completeness - if the function ain't available
> in a certain library, then it puts me off using it. Most of the
> libraries simply wrap the standard DLL's anyway.
Win32lib does a whole lot more than wrap DLL's.
> What I'm trying to say/ask is can you all develop for a single Uber-
> Library, that gives the full flexibility and completeness without
> redeveloping what each other is doing? Stick it in a single folder and
> then everyone will know where to look for info.
Still only works for constants. Win32lib does not link to a DLL routine, or
even load its library, until your application actually uses it.
> My Euphoria folders are getting cluttered up with various windowing
> libraries and it's starting to get clumsy to use.
>
> Sorry in advance if this starts a bad discussion thread - it's not meant
> as an attack on anyone, just trying to help organise things - a little!
Never give up improving things. I'm an enemy of the adage "if it ain't
broke, don't fix it.".
--
cheers,
Derek Parnell
3. Re: Standardisation between Win libraries
Hello Dave, you wrote:
> This is mainly aimed at those wonderful (and pretty darn clever) people
> out there who develop the Windows libraries (win32Lib, eWin32API, etc)
> for this great language.
.. although this issue is of general importance for Windows programming.
> Is it possible for you all to talk together and decide on a standard set
> of include files for the definitions of Windows constants ie. for
> WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
>
> With one single set of includes it would make the use of Euphoria for
> Windows soooo much easier.
<snip>
Yep! I also strongly vote for a modular approach.
For all Windows programming, there is a "smallest common denominator":
the wrapping of the Windows API! Whatever we do, we need constant and
routine declarations. It would be really valuable, to have some
_standard_ files, that wrap the Windows API. These files only should
contain:
- global constant ..
- a = open_dll(..)
- idFuncX = define_c_func(a, ..)
- global function FuncX(..)
..
return c_func(idFuncX, ..)
end function
- (same for procedures, of course)
Maybe I forgot something, but I hope you see my point. These wrappers
should not contain any "bells and whistles".
The API programmers can use it, and the programmers of the advanced
libraries (like Win32Lib) also need something like that anyway.
The problem is _not_ to write the code, there are already such API
wrapper files. I for instance use a set of files, that Chris Bensler
sent me privately. Thanks again, Chris. 
But this isn't the solution. It would be really great to have _standard_
wrappers for this purpose, and the programmers of the advanced libraries
should use them, rather than their own wrappers.
The problem is, that there currently is no agreement, which files
actually should be "the standard". Therefore probably it would be the
best, if such wrappers would be officially shipped with Euphoria (like
with other languages, such as Visual Basic, PowerBASIC, Open Watcom, ..).
Or a wrapper contibuted by users, could be "officially recommended" or
something like that.
<snip>
> Sorry in advance if this starts a bad discussion thread - it's not meant
> as an attack on anyone, just trying to help organise things - a little!
It starts a _necessary_ discussion thread.
Best regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
4. Re: Standardisation between Win libraries
Me wrote:
> Hello Dave, you wrote:
>
>> This is mainly aimed at those wonderful (and pretty darn clever) people
>> out there who develop the Windows libraries (win32Lib, eWin32API, etc)
>> for this great language.
>
> .. although this issue is of general importance for Windows programming.
>
>> Is it possible for you all to talk together and decide on a standard set
>> of include files for the definitions of Windows constants ie. for
>> WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
>>
>> With one single set of includes it would make the use of Euphoria for
>> Windows soooo much easier.
>
> <snip>
>
> Yep! I also strongly vote for a modular approach.
> For all Windows programming, there is a "smallest common denominator":
> the wrapping of the Windows API! Whatever we do, we need constant and
> routine declarations. It would be really valuable, to have some
> _standard_ files, that wrap the Windows API. These files only should
> contain:
>
> - global constant ..
> - a = open_dll(..)
> - idFuncX = define_c_func(a, ..)
> - global function FuncX(..)
> ..
> return c_func(idFuncX, ..)
> end function
> - (same for procedures, of course)
>
> Maybe I forgot something, but I hope you see my point. These wrappers
> should not contain any "bells and whistles".
> The API programmers can use it, and the programmers of the advanced
> libraries (like Win32Lib) also need something like that anyway.
>
> The problem is _not_ to write the code, there are already such API
> wrapper files. I for instance use a set of files, that Chris Bensler
> sent me privately. Thanks again, Chris.
>
> But this isn't the solution. It would be really great to have _standard_
> wrappers for this purpose, and the programmers of the advanced libraries
> should use them, rather than their own wrappers.
>
> The problem is, that there currently is no agreement, which files
> actually should be "the standard".
Sometimes I'm not very good in expressing myself, especially in a
foreign language.
The main problem regarding this issue actually seems to be, that there
is no broad agreement on this list, that having a very basic Windows API
standard wrapper is a good idea at all ...
I would be happy to contribute code and more ideas to such a wrapper,
but I don't want to work for the wastpaper basket.
BTW, recently I came across the following website.
Project: Standard Euphoria Library
http://sourceforge.net/projects/standardeu/
It looks a little dead, IMHO.
> Therefore probably it would be the
> best, if such wrappers would be officially shipped with Euphoria (like
> with other languages, such as Visual Basic, PowerBASIC, Open Watcom, ..).
> Or a wrapper contibuted by users, could be "officially recommended" or
> something like that.
>
> <snip>
>
>> Sorry in advance if this starts a bad discussion thread - it's not meant
>> as an attack on anyone, just trying to help organise things - a little!
>
> It starts a _necessary_ discussion thread.
Best regards,
Juergen
--
/"\ ASCII ribbon campain |
\ / against HTML in | Money is the root of all evil.
X e-mail and news, | Send 20 Dollars for more info.
/ \ and unneeded MIME |
5. Re: Standardisation between Win libraries
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Standardisation between Win libraries
>
>
> Me wrote:
>
> > Hello Dave, you wrote:
> >
> >> This is mainly aimed at those wonderful (and pretty darn clever) people
> >> out there who develop the Windows libraries (win32Lib, eWin32API, etc)
> >> for this great language.
> >
> > .. although this issue is of general importance for Windows programming.
> >
> >> Is it possible for you all to talk together and decide on a standard set
> >> of include files for the definitions of Windows constants ie. for
> >> WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
> >>
> >> With one single set of includes it would make the use of Euphoria for
> >> Windows soooo much easier.
> >
> > <snip>
> >
> > Yep! I also strongly vote for a modular approach.
> > For all Windows programming, there is a "smallest common denominator":
> > the wrapping of the Windows API! Whatever we do, we need constant and
> > routine declarations. It would be really valuable, to have some
> > _standard_ files, that wrap the Windows API. These files only should
> > contain:
> >
> > - global constant ..
> > - a = open_dll(..)
> > - idFuncX = define_c_func(a, ..)
> > - global function FuncX(..)
> > ..
> > return c_func(idFuncX, ..)
> > end function
> > - (same for procedures, of course)
> >
> > Maybe I forgot something, but I hope you see my point. These wrappers
> > should not contain any "bells and whistles".
> > The API programmers can use it, and the programmers of the advanced
> > libraries (like Win32Lib) also need something like that anyway.
This idea is fine so long as CONSTANT LITERALS and ROUTINE DECLARATIONS are
contained in different include files. This is because win32lib does not do a
simple "define_c_func" as a constant. It uses variables because the initial
declaration does not actually link to the DLL, that only gets done when and if
the application uses the API routine.
> > The problem is _not_ to write the code, there are already such API
> > wrapper files. I for instance use a set of files, that Chris Bensler
> > sent me privately. Thanks again, Chris.
> >
> > But this isn't the solution. It would be really great to have _standard_
> > wrappers for this purpose, and the programmers of the advanced libraries
> > should use them, rather than their own wrappers.
I agree for constant literals. However, for performance reasons, I do not link
in the hundreds of API routines at program startup, they only get linked in as
they are used.
> > The problem is, that there currently is no agreement, which files
> > actually should be "the standard".
>
> Sometimes I'm not very good in expressing myself, especially in a
> foreign language.
>
> The main problem regarding this issue actually seems to be, that there
> is no broad agreement on this list, that having a very basic Windows API
> standard wrapper is a good idea at all ...
I have no problem with this idea. But win32lib is not a low-level wrapper for
Windows. It simply can't use a 'statically' linked DLL such as you propose.
Also note that the thousands of constant literals would always all be assigned
and placed in RAM by the interpreter. So if your code only need a few dozen of
these constants, you will have lots of wasted RAM and progam startup time wasted.
--
Derek
6. Re: Standardisation between Win libraries
----=_6es0iv83csi4qi5h6ad975116go7iip3v1.MFSBCHJLHS
I'd just like to remind everyone that Jacques Deschenes posted a file
back in 1999 containing nearly 6000 constants;
I have a copy of lcc which comes with 325+ header files, many of which
are trivial, but one of which I know contains 16,600+ lines (not all
constants, but the point is made).
In contrast, my own ppconst.e contains just the constants my program
needs (and a fair few it don't), is only 341 lines long (including
some from get.e, database.e, etc). And my program is far from being
trivial !! (Watch this space).
I would like to see a w32const.ew file, for searching purposes, but:
a) it would be up to Derek to create that if he chooses, and
he/win32lib would gain little to nothing from doing so.
b) it is obviously up to Arwen/WinMania/Llama/etc to use that, if they
so chose, and they may well not, same deal.
c) some mechanism would need to be in place that any mod to said file
does not crash any other install. Fundamentally, that is not possible.
SUMMARY
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I ain't gona happen. It is easy to create your own mini-lib for the
things you need. I've attached mine, if someone wants to make this
their pet project (proving it works with everything mentioned above
and more besides) let us know.
Pete
PS Rob/all, the Microsoft link for "WIN32 API Constant Declarations"=20
http://members.tripod.com/~JJProg/win32api.zip (1995) is dead.
>> >> With one single set of includes it would make the use of Euphoria =
for
>> >> Windows soooo much easier.
An actual example might convince more readily than such a blanket
statement.
----=_6es0iv83csi4qi5h6ad975116go7iip3v1.MFSBCHJLHS
Content-Type: application/octet-stream; name=ppconst.ZIP
7. Re: Standardisation between Win libraries
On Fri, 25 Jul 2003 00:54:46 +0100, Pete Lomax
<petelomax at blueyonder.co.uk> wrote:
>I ain't gona happen.
Er, I have actually happened, I think.
I meant "It ain't going to happen" 
Pete
8. Re: Standardisation between Win libraries
Also, libraries such as Llama would have a near impossible time with this.
(Short of wrapping Wine or emulating the entire win32 api, there is no way
to port such wrappers on Linux.)
If Derek were to use such a wrapper in win32lib, then every win32lib program
that called wrapper functions directly would break on porting to Llama.
(Same today for win32lib programs that use w32func() or w32proc().)
[Note that this is ignoring how far behind from win32lib Llama is currently...
so basicly any complex win32lib program would break on Llama due to features
which have yet to be implemented.]
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
9. Re: Standardisation between Win libraries
----- Original Message -----=20
From: "Dave Probert" <zingo at purpletiger.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Standardisation between Win libraries
>=20
>=20
> Phew, I guess it's more difficult than I first thought.
Like most things in life
=20
> So, basically we're looking at many MS Windows (ignoring Linux at the=20
> moment - sorry) libraries, that each do much the same thing, but with=20
> differences (bits missed, etc). Each of them written to manage the=20
> tasks that the writer wanted to do at the time, but not complete =
enough=20
> for a wider range of tasks. Each of them sits somewhere on the =
Euphoria=20
> Path and there can, potentially, be many copies of them (Lots of =
people=20
> supply a copy of win32Lib, ewin32API, win32R, etc; along with their=20
> application) - I already have 12 copies of win32lib that came in =
various=20
> zips.
Yep, that about sums it up.
=20
> I agree with Derek on the sensibilities of not simply including ALL =
the=20
> function even if not needed. I'm not sure about the absolute need for =
> cross-platform All-In-One type of library development - shouldn't =
there=20
> be a wrapper or different set of (same name) files to be included when =
> going to another platform?
Ahhh..the perfect world concept again...hmmmm.
> A more modular and heirarchical approach to the library designs is=20
> probably what I'm trying to describe. One that would allow the base=20
> functionality to be there, but with the ability to extend it beyond =
that=20
> in various ways without touching (ie modifying) the base code. =
Nothing=20
> new there - been done before in many languages.
Yep, it sure has. The Euphoria user base is so small and uncoordinated =
(read: not-paid) that a central Eu standards body is not all that =
feasible. And RDS does not want that role either.
> The Standard Euphoria Library does seem to be dead, but it's a sound=20
> idea - especially for Windows development. Looking through many files =
I=20
> see repetition of so many functions and slight variations on functions =
> (eg. or_all() and or_all_bits() ) - that strikes me as simply a lack =
of=20
> some further core libraries which we all could benefit from.
Hear, hear! One of the first things that new Eu coders find, after =
getting over the intro stuff, is that they have to go an reinvent many =
things that are taken as normally available in other languages. How many =
copies of abs() do we really need!? RDS should be a lot more proactive =
in packaging the commonly re-invented library routines - even if it =
means that RDS takes responsiblility in maintaining them. The continual =
mess of amorphous sub-committees for "Eu Standard Library" is adding to =
the frustration.
> What are the benefits of each of the current Windows libraries anyway?
Win32lib attempts to make coding apps for MS-Windows easier and faster =
to do; trading execution speed for development speed.
> What are the differences? =20
I think that other WIN libraries either go for faster execution speeds =
and/or cross-platform functionality.
>Which Library is the most used? =20
Win32lib, of course
>What can be done to help improve (and/or merge ) the libraries=20
>(or preferably one)
Nothing, as they have different (mutually exclusive) goals to achieve.
> Still not an attack, just a discussion from a new Euphoria user who's =
a=20
> little confused, having come from the C/C++/Java/PHP/ActionScript=20
> world!! :)
And in spite of this lack of 'core' functionality, I still find myself =
liking Euphoria more and more. 'Chaos Theory' in action.
--=20
Derek
10. Re: Standardisation between Win libraries
On Fri, Jul 25, 2003 at 07:34:59PM +0000, Dave Probert wrote:
> So, basically we're looking at many MS Windows (ignoring Linux at the
> moment - sorry) libraries,
<snip>
Just wait until I get winux out ... hehe. ;]
jbrown
P.S. winux is an attempt of mine to provide access to an emulation of the
Win32API
to Linux programs. Once I get it up and running then it should theoreticly
make porting of such libraries as win32lib to linux trivial.
--
/"\ 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: Standardisation between Win libraries
Hello Derek, you wrote:
> ----- Original Message -----
> From: "Juergen Luethje"
>
>> Me wrote:
>>
>>> Hello Dave, you wrote:
<snip>
>>>> Is it possible for you all to talk together and decide on a standard set
>>>> of include files for the definitions of Windows constants ie. for
>>>> WM_PAINT, WM_MOUSEMOVE, VK_SPACE, VK_LEFT, etc? and/or other aspects.
>>>>
>>>> With one single set of includes it would make the use of Euphoria for
>>>> Windows soooo much easier.
>>>
>>> <snip>
>>>
>>> Yep! I also strongly vote for a modular approach.
>>> For all Windows programming, there is a "smallest common denominator":
>>> the wrapping of the Windows API! Whatever we do, we need constant and
>>> routine declarations. It would be really valuable, to have some
>>> _standard_ files, that wrap the Windows API. These files only should
>>> contain:
>>>
>>> - global constant ..
>>> - a = open_dll(..)
>>> - idFuncX = define_c_func(a, ..)
>>> - global function FuncX(..)
>>> ..
>>> return c_func(idFuncX, ..)
>>> end function
>>> - (same for procedures, of course)
>>>
>>> Maybe I forgot something, but I hope you see my point. These wrappers
>>> should not contain any "bells and whistles".
>>> The API programmers can use it, and the programmers of the advanced
>>> libraries (like Win32Lib) also need something like that anyway.
>
> This idea is fine so long as CONSTANT LITERALS and ROUTINE DECLARATIONS
> are contained in different include files.
Yes, I think this is a good idea anyway. In case someone wants it, it's
easy to combine different files (logically or physically). The other way
round, splitting one huge file into small pieces if needed, is not that
easy.
> This is because win32lib does not do a simple "define_c_func" as a
> constant. It uses variables because the initial declaration does not
> actually link to the DLL, that only gets done when and if the
> application uses the API routine.
Ah, I see. When I first read this, I was thinking of something along the
lines of the following sample code:
---------------------------[ File user32.ew ]---------------------------
include dll.e
atom user32
user32 = -1
procedure link_user32()
user32 = open_dll("user32.dll")
if user32 = 0 then
-- error
end if
end procedure
--====================================================================--
integer idLoadCursor idLoadCursor = 0
global function LoadCursor (atom hInstance, atom lpCursorName)
-- Initialisation
if user32 = -1 then link_user32() end if
if idLoadCursor = 0 then
idLoadCursor = define_c_func(user32, "LoadCursorA",
{C_INT, C_POINTER}, C_INT)
if idLoadIcon = -1 then
-- error
end if
end if
-- Actual function call
return c_func(idLoadCursor, {hInstance, lpCursorName})
end function
---------=---------=---------=---------=---------=---------=--------
integer idLoadIcon idLoadIcon = 0
global function LoadIcon (atom hInstance, atom lpIconName)
-- Initialisation
if user32 = -1 then link_user32() end if
if idLoadIcon = 0 then
idLoadIcon = define_c_func(user32, "LoadIconA",
{C_INT, C_POINTER}, C_INT)
if idLoadIcon = -1 then
-- error
end if
end if
-- Actual function call
return c_func(idLoadIcon, {hInstance, lpIconName})
end function
---------=---------=---------=---------=---------=---------=--------
But then I looked at Win32Lib and saw, that it handles the linking to
DLLs in a more complex way ...
>>> The problem is _not_ to write the code, there are already such API
>>> wrapper files. I for instance use a set of files, that Chris Bensler
>>> sent me privately. Thanks again, Chris.
>>>
>>> But this isn't the solution. It would be really great to have _standard_
>>> wrappers for this purpose, and the programmers of the advanced libraries
>>> should use them, rather than their own wrappers.
>
> I agree for constant literals.
So we should a least try do define/create such a standard.
> However, for performance reasons, I do
> not link in the hundreds of API routines at program startup, they only
> get linked in as they are used.
>
>>> The problem is, that there currently is no agreement, which files
>>> actually should be "the standard".
>>
>> Sometimes I'm not very good in expressing myself, especially in a
>> foreign language.
>>
>> The main problem regarding this issue actually seems to be, that there
>> is no broad agreement on this list, that having a very basic Windows API
>> standard wrapper is a good idea at all ...
>
> I have no problem with this idea. But win32lib is not a low-level
> wrapper for Windows. It simply can't use a 'statically' linked DLL such
> as you propose.
>
> Also note that the thousands of constant literals would always all be
> assigned and placed in RAM by the interpreter. So if your code only
> need a few dozen of these constants, you will have lots of wasted RAM and
> progam startup time wasted.
I see. But anyway it would be a good idea IMHO, to have a huge
collection of constant literals. Then it's simply a mattor of search,
copy, and paste, do get them in our code.
(That's even more important for routine declarations. Before I had
Chris's API wrapper files, I always had to look in win32api files
provided by PowerBASIC for the routine declarations, and translate
them to Euphoria. That was a pain.)
Including only the constant literals and routine declarations in our
programs, that are actually needed, would be a good job for a
preprocessor, IMHO. Or for instance a "generic" IDE (as it is
apparently planned ATM could provide the possibility to insert
the needed declarations into the code by choosing them from a list.
Also, including many unneeded constant literals and routine declarations
does *not* slow down a bound or a shrouded program.
Therefore I would really like to have an additional option for shrouding,
say '-very clear' or '-preserve', that will do the same as '-clear',
but not remove comments and indenting white space. Preserving the
comments and the indentation will be useful anyway, when we want to ship
a single source file (unless the file is very big). Rob, what do you
think?
Well, I'm just trying to collect some ideas ...
Best regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
12. Re: Standardisation between Win libraries
Hello Derek, you wrote:
> ----- Original Message -----
> From: "Dave Probert"
>
>
>> Phew, I guess it's more difficult than I first thought.
>
> Like most things in life
<snip>
>> A more modular and heirarchical approach to the library designs is
>> probably what I'm trying to describe. One that would allow the base
>> functionality to be there, but with the ability to extend it beyond that
>> in various ways without touching (ie modifying) the base code. Nothing
>> new there - been done before in many languages.
>
> Yep, it sure has. The Euphoria user base is so small and uncoordinated
> (read: not-paid) that a central Eu standards body is not all that
> feasible. And RDS does not want that role either.
Well, I think to a certain degree RDS plays that role, regardless
whether they want it or not. There is something that a German
philosopher called "die normative Kraft des Faktischen" -- ad hoc
translation by me: "the normative power of facts".
That means roughly, that some things, if they exist for a certain time
(and if they fit certain needs, or there is no alternative), then these
things become a standard in their respective field.
(I hope this was at least understandable English.)
See below for further explanation.
>> The Standard Euphoria Library does seem to be dead, but it's a sound
>> idea - especially for Windows development. Looking through many files I
>> see repetition of so many functions and slight variations on functions
>> (eg. or_all() and or_all_bits() ) - that strikes me as simply a lack of
>> some further core libraries which we all could benefit from.
>
> Hear, hear! One of the first things that new Eu coders find, after
> getting over the intro stuff, is that they have to go an reinvent many
> things that are taken as normally available in other languages. How many
> copies of abs() do we really need!?
This also concerns for instance
- poke2()
- peek2s()
- peek2u()
- peek_string()
- hi_word()
- lo_word()
> RDS should be a lot more proactive
> in packaging the commonly re-invented library routines - even if it
> means that RDS takes responsiblility in maintaining them.
<snip>
And just by doing so, RDS will create a standard, that will be accepted
by anyone. They already did so in the past by providing the existing
library functions. That's exactly what I meant.
Best regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
13. Re: Standardisation between Win libraries
Hello Peter, you wrote:
> Just my take on this subject,
>
> Choice is good !
>
> Take a look at the windows platform and see what happens when
> there is just one option. If you need other functionality or
> options, you are out of luck.
>
> For example, I've just switched my windows machines from using
> the windows shell (explorer) to using Litestep instead. Now, for
> Litestep there are several desktop modules, tasktray modules,
> menu modules, etc. to choose from. Each with different options
> and functionality. It takes some time to figure out which ones
> you want to use, but in the end you get (close to) exactly what
> YOU want.
>
> I think the same goes for the Euphoria libraries: choice is good !
>
> So my vote is "Please DON'T merge them into one".
Yep, I totally agree.
But please note, that modularity (if possible) increases the number of
choices.
Best regards,
Juergen
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
14. Re: Standardisation between Win libraries
Juergen Luethje wrote:
> Therefore I would really like to have an additional option for shrouding,
> say '-very clear' or '-preserve', that will do the same as '-clear',
> but not remove comments and indenting white space. Preserving the
> comments and the indentation will be useful anyway, when we want to ship
> a single source file (unless the file is very big). Rob, what do you
> think?
That should be easy to do.
I'll make a note of your suggestion.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
15. Re: Standardisation between Win libraries
On Sat, Jul 26, 2003 at 06:35:13AM +0000, Peter Willems wrote:
>
>
> jbrown105 at speedymail.org wrote:
>
> > Just wait until I get winux out ... hehe. ;]
> >
> > P.S. winux is an attempt of mine to provide access to an emulation of
> > the Win32API
> > to Linux programs. Once I get it up and running then it should
> > theoreticly
> > make porting of such libraries as win32lib to linux trivial.
>
> I was thinking myself to write another "wrapper"that can wrap
> different libraries (on windows and linux) and make them available
> to my program without changes so I could port stuff to linux fast.
>
> It seems that your idea will solve it already
>
> Hans Peter Willems
>
If I can get it to work. Basicly its an attempt to use IPC between a Linux
exu program and a Windows exw program (the exw is running via WINE).
I'm using TCP/IP sockets for it, but for some reason its not working. :/
(The linux part uses my socketlib.eu, the Windows part uses tcp4u.)
jbrown
PS I'd be grateful for any help on this and will give the code on demand.
>
>
> 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
16. Re: Standardisation between Win libraries
On Sun, Jul 27, 2003 at 04:46:40PM +0000, Peter Willems wrote:
>
>
> jbrown105 at speedymail.org wrote:
>
> > If I can get it to work. Basicly its an attempt to use IPC between a
> > Linux
> > exu program and a Windows exw program (the exw is running via WINE).
>
> Ah.... my idea was more aimed at porting code from windows to
> linux (or freeBSD for that matter). I was thinking about writing
> a wrapper for win32lib and one for some linux lib, making the
> interface for both wrappers identical so I could simply plug in
> the appropriate wrapper to have my programs running on both
> platforms.
Actually that was the idea behind Llama, which I am also working on. (Llama
is the Linux/BSD wrapper for Win32lib.)
>
> <snip>
> > PS I'd be grateful for any help on this and will give the code on
> > demand.
>
> I don't think I can help you there. TCP stuff is not realy my
> strong point.
>
Oh well. Maybe someone else will volneteer...I hope.
> 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
17. Re: Standardisation between Win libraries
- Posted by gertie at visionsix.com
Jul 27, 2003
On 27 Jul 2003, at 12:55, jbrown105 at speedymail.org wrote:
>
>
> On Sun, Jul 27, 2003 at 04:46:40PM +0000, Peter Willems wrote:
> >
> >
> > jbrown105 at speedymail.org wrote:
> >
> > > If I can get it to work. Basicly its an attempt to use IPC between a
> > > Linux
> > > exu program and a Windows exw program (the exw is running via WINE).
> >
> > Ah.... my idea was more aimed at porting code from windows to
> > linux (or freeBSD for that matter). I was thinking about writing
> > a wrapper for win32lib and one for some linux lib, making the
> > interface for both wrappers identical so I could simply plug in
> > the appropriate wrapper to have my programs running on both
> > platforms.
>
> Actually that was the idea behind Llama, which I am also working on. (Llama is
> the Linux/BSD wrapper for Win32lib.)
>
> >
> > <snip>
> > > PS I'd be grateful for any help on this and will give the code on
> > > demand.
> >
> > I don't think I can help you there. TCP stuff is not realy my
> > strong point.
> >
>
> Oh well. Maybe someone else will volneteer...I hope.
Back in the few years ago, Greg Harris, Robs, Mario (i hope i haven;t let
anyone out, or included the wrong people!) and i did a tcp internet connection
with mirc-eu. Outside the irc and mirc code, Eu did the connection between
us. Greg actually coded the Eu side to *stop* more than one connection, but
for a beowulfish cluster on a lan, remove the security code, run it behind a
firewall, and it would click along as fast as your LAN would allow, and
doesn't matter what OS the boxes on the LAN are, and long as they know
how to talk to each other. In tests, it ran as fast as our internet connection
on the internet, and ran sustained send and recieve about 1.2megbyte(?)
localhost. After we got it working, everyone drifted apart, and no one was
interested in sharing via RPC anymore. I dunno why. What is executeable
was naturally restricted by whatever we wanted.
Kat
18. Re: Standardisation between Win libraries
On Sun, Jul 27, 2003 at 02:16:36PM -0500, gertie at visionsix.com wrote:
>
>
> On 27 Jul 2003, at 16:46, Peter Willems wrote:
>
> >
> > jbrown105 at speedymail.org wrote:
> >
> > > If I can get it to work. Basicly its an attempt to use IPC between a
> > > Linux
> > > exu program and a Windows exw program (the exw is running via WINE).
> >
> > Ah.... my idea was more aimed at porting code from windows to
> > linux (or freeBSD for that matter). I was thinking about writing
> > a wrapper for win32lib and one for some linux lib, making the
> > interface for both wrappers identical so I could simply plug in
> > the appropriate wrapper to have my programs running on both
> > platforms.
> >
> > <snip>
> > > PS I'd be grateful for any help on this and will give the code on
> > > demand.
> >
> > I don't think I can help you there. TCP stuff is not realy my
> > strong point.
>
> Did anyone note the latest security bugs in ALL windows OSs for RPC,
> which incidently isn't IPC, but RPC does use TCP.
>
> Kat
>
You do realize winux is a LINUX project, not a Windows one, right?
No Winux code will be run under any native Windows OS.
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
19. Re: Standardisation between Win libraries
On Sun, Jul 27, 2003 at 02:16:36PM -0500, gertie at visionsix.com wrote:
<snip>
> Back in the few years ago, Greg Harris, Robs, Mario (i hope i haven;t let
> anyone out, or included the wrong people!) and i did a tcp internet connection
>
> with mirc-eu. Outside the irc and mirc code, Eu did the connection between
> us. Greg actually coded the Eu side to *stop* more than one connection, but
> for a beowulfish cluster on a lan, remove the security code, run it behind a
> firewall, and it would click along as fast as your LAN would allow, and
> doesn't matter what OS the boxes on the LAN are, and long as they know
> how to talk to each other. In tests, it ran as fast as our internet connection
>
> on the internet, and ran sustained send and recieve about 1.2megbyte(?)
> localhost. After we got it working, everyone drifted apart, and no one was
> interested in sharing via RPC anymore. I dunno why. What is executeable
> was naturally restricted by whatever we wanted.
>
> Kat
>
What does that have to do with winux?
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
20. Re: Standardisation between Win libraries
On Sun, Jul 27, 2003 at 12:20:49PM -0700, eugtk at yahoo.com wrote:
>
>
> --- Peter Willems <peter at integratedmoves.com> wrote:
>
> > Ah.... my idea was more aimed at porting code
> > from windows to
> > linux (or freeBSD for that matter). I was
> > thinking about writing
> > a wrapper for win32lib and one for some linux
> > lib, making the
> > interface for both wrappers identical so I could
> > simply plug in
> > the appropriate wrapper to have my programs
> > running on both
> > platforms.
>
> An interesting idea, but one which would probably be
> unappealing to both Windows and Linux users, because
> each platform has some very good features which simply
>
> aren't available on the other. Anything written
> to run on both platforms would be limited to only
> those things they both have in common, and would
> thereby lack the niceties that users have become
> accustomed to.
Unforutantly true. However the library(ies) itself need not suffer from this:
it merely need unite what the platforms have in common into a standard
interface (i.e. CreateWindow(), WriteWindow(), etc for Linux/BSD/Win32) and
then add the per-platform nicies to the per-platform include file. The Linux
nices wont work on win32 and vice versa, but at least the library would support
both (and in theory might be able to eventually provide emulation on the other
platforms).
>
> Regards,
> Irv
>
>
>
> 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
21. Re: Standardisation between Win libraries
- Posted by gertie at visionsix.com
Jul 27, 2003
On 27 Jul 2003, at 15:34, jbrown105 at speedymail.org wrote:
>
>
> On Sun, Jul 27, 2003 at 02:16:36PM -0500, gertie at visionsix.com wrote:
> <snip>
> > Back in the few years ago, Greg Harris, Robs, Mario (i hope i haven;t let
> > anyone out, or included the wrong people!) and i did a tcp internet
> > connection
> > with mirc-eu. Outside the irc and mirc code, Eu did the connection between
> > us.
> > Greg actually coded the Eu side to *stop* more than one connection, but for
> > a
> > beowulfish cluster on a lan, remove the security code, run it behind a
> > firewall, and it would click along as fast as your LAN would allow, and
> > doesn't matter what OS the boxes on the LAN are, and long as they know how
> > to
> > talk to each other. In tests, it ran as fast as our internet connection on
> > the
> > internet, and ran sustained send and recieve about 1.2megbyte(?) localhost.
> > After we got it working, everyone drifted apart, and no one was interested
> > in
> > sharing via RPC anymore. I dunno why. What is executeable was naturally
> > restricted by whatever we wanted.
> >
> > Kat
> >
>
> What does that have to do with winux?
Not a damned thing, jbrown. But didn't someone in this thread mention RPC
via TCP?
Kat
22. Re: Standardisation between Win libraries
On Sun, Jul 27, 2003 at 03:50:13PM -0500, gertie at visionsix.com wrote:
<snip>
>
> Not a damned thing, jbrown. But didn't someone in this thread mention RPC
> via TCP?
>
> Kat
>
Um, I don't think so... but the thread about Al Getz's Display Server did.
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
23. Re: Standardisation between Win libraries
Hi Rob, you wrote:
> Juergen Luethje wrote:
>> Therefore I would really like to have an additional option for shrouding,
>> say '-very clear' or '-preserve', that will do the same as '-clear',
>> but not remove comments and indenting white space. Preserving the
>> comments and the indentation will be useful anyway, when we want to ship
>> a single source file (unless the file is very big). Rob, what do you
>> think?
>
> That should be easy to do.
> I'll make a note of your suggestion.
I'd really appreciate it.
> Thanks,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
I have to thank you.
Best regards,
Juergen
--
The difference between men and boys
is the price of the toys.
