1. Source changes
A few hours ago, I checked in the changes related to value() and get(), so that
they both return 4 element sequences. I didn't test the generated docs.
I also created a branch that also fixes the (documented) bug where get() reads
an extra character when reading a top level number from a file. get() now reads a
file containing "3.3333{2,5}" correctly.
Since this concerns a sensitive issue - file I/O - where extensive testing is
needed on all supported platforms and compilers, which I cannot do all by myself,
I created a branch in the repository for that code, in the hope that some will
test it and detect any bug or performance penalty.
When the code is validated in both ways, after any needed fix, it will be easily
merged back to mainstream.
CChris
2. Re: Source changes
CChris wrote:
> A few hours ago, I checked in the changes related to value() and get(), so
> that
> they both return 4 element sequences. I didn't test the generated docs.
<snip>
Rob,
please do not put these changes into the next Euphoria release.
Regards,
Juergen
3. Re: Source changes
Juergen Luethje wrote:
>
> CChris wrote:
>
> > A few hours ago, I checked in the changes related to value() and get(), so
> > that
> > they both return 4 element sequences. I didn't test the generated docs.
>
> <snip>
>
> Rob,
>
> please do not put these changes into the next Euphoria release.
I can understand your concerns about keeping things
simple, but I'm not going to veto this change. I doubt that
it will cause much, if any, code to break. Christian should listen
carefully to the arguments of others on this forum, but if he
still thinks it's a good idea, then it's OK with me if he proceeds.
People who take the time to learn SVN, and who do the actual
programming work, should be given the benefit of the doubt
on small changes like this. Besides, in the future, if there are
any bugs in get() or value(), we'll have someone to turn to,
other than me. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Source changes
Robert Craig wrote:
>
> Juergen Luethje wrote:
> >
> > CChris wrote:
> >
nice call, Rob. i've always been appreciative of the development and growth of
Euphoria and, especially lately, the maturity of you and the community.
thanks.
--
jon
5. Re: Source changes
Agreed.
While I was skeptical about the changes at first Christian's description of them
sound like they will work well without breaking any backwards compatibility,
especially since the same info will be exposed by both get and value.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
6. Re: Source changes
Robert Craig wrote:
>
> Juergen Luethje wrote:
> >
> > CChris wrote:
> >
> > > A few hours ago, I checked in the changes related to value() and get(), so
> > > that
> > > they both return 4 element sequences. I didn't test the generated docs.
> >
> > <snip>
> >
> > Rob,
> >
> > please do not put these changes into the next Euphoria release.
>
> I can understand your concerns about keeping things
> simple, but I'm not going to veto this change. I doubt that
> it will cause much, if any, code to break. Christian should listen
> carefully to the arguments of others on this forum, but if he
> still thinks it's a good idea, then it's OK with me if he proceeds.
> People who take the time to learn SVN, and who do the actual
> programming work, should be given the benefit of the doubt
> on small changes like this. Besides, in the future, if there are
> any bugs in get() or value(), we'll have someone to turn to,
> other than me.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Further, as I have listened carefully, I heard that:
1/ some people, perhaps many of them, are looking for a function that converts a
string into a numerical value and hardly anything else. Derek Parnell hinted that
he would submit a tidied up version of w32to_number().
2/ If I understand well what has been said, many people will switch to that
function and leave value() alone anyway. This will certainly decrease the amount
of possible groaning, as w32to_number(), or whatever it will be eventually named,
will be "simpler" (= return less data? not sure, but oh well).
3/ Obviously I'm here to fix the bugs that I'd have introduced.
CChris
7. Re: Source changes
CChris wrote:
> 1/ some people, perhaps many of them, are looking for a function that converts
> a string into a numerical value and hardly anything else. Derek Parnell hinted
> that he would submit a tidied up version of w32to_number().
> 2/ If I understand well what has been said, many people will switch to that
> function and leave value() alone anyway. This will certainly decrease the
> amount
> of possible groaning, as w32to_number(), or whatever it will be eventually
> named,
> will be "simpler" (= return less data? not sure, but oh well).
I've started the process. I'm packaging this function plus a few others into a
new library, whose purpose will be to contain text conversion routines. Thus a
new library called "convtext.e" will be added to the Euphoria include folder. It
will contain a set of related functions that convert text strings into numbers
and visa versa.
-- Proposed Routines --
This set will attempt to convert the text to the requested format, but if
they are unable to they do not fail, instead they return zero.
toInteger(sequence TextIn) -- converts the text to an integer.
toNumber(sequence TextIn) -- converts the text to an integer or atom as
-- appropriate.
toDigits(sequence TextIn) -- converts the text to an integer or atom as
-- appropriate, but disregards all non-digits
-- except the first decimal-separator.
toBase(sequence TextIn, integer Base) -- converts the text to an
-- integer or atom as appropriate,
-- but disregards all non-digits as
-- defined by the 'number-base'
-- supplied.
This set will attempt to convert the text to the requested format, but if
they are unable to they do not fail, instead they return a sequence containing
the position in the input where conversion stopped, and the result of the
conversion as at that point.
CInt(sequence TextIn) -- converts the text to an integer.
CNum(sequence TextIn) -- converts the text to an integer or atom as
-- appropriate.
This set will test the text for conversion but will not actually convert it,
instead they return a true/false value.
isInteger(sequence TextIn) -- checks that the text could be converted
-- to an integer
isNumber(sequence TextIn) -- checks that the text could be converted
-- to an integer or atom
Those routines will allow for decimal-separators, number-grouping, leading sign
(+/-) or trailing sign, currency symbol, scientific notation, number-bases from 2
to 94, parenthetical negatives, and scaling symbols.
The user will be able to set the values for decimal-separator, number-groups,
currency symbols, and scaling symbols. By default they will be set to ".", ",_ ",
"$¢£¤¥₣₤₧₪₫€", and "%‰" (unicode only).
This next function takes a sequence of text strings and returns the same
sequence but with as many strings as possible converted to numbers.
makeNumbers(sequence RecordData)
e.g. makeNumbers({"Derek", "Parnell", "555 7748", "19", "North Road"})
would return
{"Derek", "Parnell", 5557748, 19, "North Road"}
This set of routines converts a number to a text string, some using locale
settings.
StringInt( integer Data )
StringNumber( atom Data )
StringFormat( atom Data, sequence Format)
DateFormat ( sequence Data, sequence Format)
TimeFormat ( atom Data, sequence Format)
CurrencyFormat (atom Data)
This library can also be used for other text conversions as the need arises.
Comments please...
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
8. Re: Source changes
Derek wrote ..
This set will attempt to convert the text to the requested format, but if
they are unable to they do not fail, instead they return zero.
Derek, how about always returning a sequence with the first atom being
the return code? Otherwise I would not know the difference if the data to
be evaluated resolved to zero, and a function failure.
Regards
Alan
9. Re: Source changes
I welcome the proposed routines as I regularly use similar ones.
The only thing I am opposed to is the CamelCase routine names.
Euphoria (in general) doesn't use it. See:
-- find_from
-- match_from
-- custom_sort
I would suggest to use
to_int(sequence TextIn)
to_number(sequence TextIn)
to_digits(sequence TextIn)
to_base(sequence TextIn, integer Base) --
integer or atom as appropriate,
-- etc.
}}}
<eucode>
At the same time I am aware of the Win32lib routine names
and the different preferences of the programmers. (See the
"Aesthetically pleasing identifier names" discussion in this
list.) And obviously it's up to you...
Could you write a few more words about the following ones?
The most problems I have with these conversions. (Specially
the lack of date and time functions.)
}}}
<eucode>
DateFormat(sequence Data, sequence Format)
TimeFormat(atom Data, sequence Format)
CurrencyFormat (atom Data)
Rgds,
Salix
P.S.: Whops. I mean these ones. 
date_format(sequence Data, sequence Format)
time_format(atom Data, sequence Format)
curr_format (atom Data)
10. Re: Source changes
I disagree with the underscore names. They're just difficult to type.
11. Re: Source changes
Alan Oxley wrote:
>
> Derek wrote ..
> This set will attempt to convert the text to the requested format, but if
> they are unable to they do not fail, instead they return zero.
>
> Derek, how about always returning a sequence with the first atom being
> the return code? Otherwise I would not know the difference if the data to
> be evaluated resolved to zero, and a function failure.
I've catered for this too in that all the 'to_xxx' routines will have an
equivalent 'conv_xxx' routine. The 'to_xxx' is designed to always return a number
because there are situations in which this is acceptable to do, and the
'conv_xxx' returns a sequence if it fails and a number if it succeeds.
The usage of 'conv_xxx' depends on what the application expects to be in the
text. For example...
object result
sequence inp
inp = getField(fldCosting) --> "$123.45 per Item"
result = conv_atom(inp) --> {123.45,8}
if sequence(result) then
cost = result[1]
description = inp[result[2]..$]
else
cost = result
description = ""
end if
And in another usage it might be more like ...
result = {}
while sequence(result) do
inp = ask_user("Enter your age") --> "I'm 19 years old"
result = conv_integer(inp) --> {0,1}
if sequence(result) then
msg("You must enter your age as a simple number (of years)")
else
user_age = result
end if
end while
or using the 'to_xxx' routine:
result = 0
while result < 1 or result > 99 do
inp = ask_user("Enter your age") --> "I'm 19 years old"
result = to_number(inp) --> 0
if result < 1 or result > 99 then
msg("You must enter your age as a simple number between 1 and 99")
else
user_age = result
end if
end while
But note that to_digits() would have returned 19 because it discards all
non-digits.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
12. Re: Source changes
Salix wrote:
>
> I welcome the proposed routines as I regularly use similar ones.
> The only thing I am opposed to is the CamelCase routine names.
> Euphoria (in general) doesn't use it.
You're correct. To be consistent the underscore names would be better.
> Could you write a few more words about the following ones?
> The most problems I have with these conversions. (Specially
> the lack of date and time functions.)
The commonly used date format is {YYYY,MM,DD, ...} but the Epoch form is also
used. There are at least two good date-time libraries in the User Contributions
section so I'd suggest that we combine the good aspects of those into a single
officially-supported library.
I imagine that the formatting codes for format_date() and format_time() will be
along the lines of the unix date command.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
13. Re: Source changes
George Walters wrote:
>
> I disagree with the underscore names. They're just difficult to type.
Yeah, I don't like them either but consistency will have to overrule here.
We can always create shim routines ...
function FormatDate(object a, object b)
return format_date(a,b)
end function
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
14. Re: Source changes
Derek Parnell wrote:
>
> Comments please...
>
>a new library called "convtext.e" will be added to Euphoria include folder.
Good. A new include file means less impact on legacy code.
The idea of a user-definable callback, like walk_dir()/default_dir() in file.e,
still appeals to me as you can make it dead easy for newbies but still have fine
control for advanced coders.
Did you have any comments on my proposed changes to get.e?
http://palacebuilders.pwp.blueyonder.co.uk/pc.htm
I accept the above is not going to be used, and that instead of passing a
routine_id on every call, an optional set() at the start would be better.
>
> -- Proposed Routines --
> This set will attempt to convert the text to the requested format, but if
> they are unable to they do not fail, instead they return zero.
>
> toInteger(sequence TextIn) -- converts the text to an integer.
> toNumber(sequence TextIn) -- converts the text to an integer or atom as
> -- appropriate.
> toDigits(sequence TextIn) -- converts the text to an integer or atom as
> -- appropriate, but disregards all non-digits
> -- except the first decimal-separator.
> toBase(sequence TextIn, integer Base) -- converts the text to an
> -- integer or atom as appropriate,
> -- but disregards all non-digits as
> -- defined by the 'number-base'
> -- supplied.
Just as an idea, I wonder:
text_to_data(INTEGER,xxx)
text_to_data(ATOM,xxx)
text_to_data(DIGITS,xxx)
text_to_data({BASE,12},xxx)
Extendable with strings and sequences and dates and times and wotnot that way.
This is also very value()-sided, no equivalent get() routines.
> Those routines will allow for decimal-separators, number-grouping,
I got lost here. I could't work out if you meant all the routines mentioned in
the post, the ones just above, or the ones after that point. Actually, I think
I'd like to see RDS-style docs for these new routines up front.
> StringInt( integer Data )
> StringNumber( atom Data )
> StringFormat( atom Data, sequence Format)
Without examples I see no gain over sprint(f).
> DateFormat ( sequence Data, sequence Format)
> TimeFormat ( atom Data, sequence Format)
> CurrencyFormat (atom Data)
I would, for example, hope to see in RDS-style docs that DateFormat etc should
only be used for display and reporting purposes; saving data to file should use
the rawest possible format, eg {2007,7,2} not "2nd July 2007", otherwise a user
in a different locale may not be able to read the data.
Regards,
Pete
15. Re: Source changes
Ok Derek,
So if your "to_xxxx" routines only return data,
and the "conv_xxxx" also indicate conversion success,
I guess I will be my usual pedantic self ;)
and always call conv_xxxx !
Thanks for your efforts -
It looks like you are putting in double work to cater for all.
Cheers
Alan
16. Re: Source changes
Robert Craig wrote:
> Juergen Luethje wrote:
>> CChris wrote:
>>
>>> A few hours ago, I checked in the changes related to value() and get(), so
>>> that
>>> they both return 4 element sequences. I didn't test the generated docs.
>>
>> <snip>
>>
>> Rob,
>>
>> please do not put these changes into the next Euphoria release.
>
> I can understand your concerns about keeping things
> simple, but I'm not going to veto this change. I doubt that
> it will cause much, if any, code to break.
Backwards compatibility is not my main concern. However, for the sake of
completeness: The proposed change will cause code to break such as
if equal(value(s), {GET_SUCCESS,a}) then
> Christian should listen
> carefully to the arguments of others on this forum, but if he
> still thinks it's a good idea, then it's OK with me if he proceeds.
> People who take the time to learn SVN, and who do the actual
> programming work, should be given the benefit of the doubt
> on small changes like this.
Sorry, I disagree.
While knowledge of C and SVN is necessary to make changes to the
language, this does not mean that everyone who meets these requirements
will make sensible changes. Sometimes (often?) less is more, and
sometimes (often?) it is better _not_ do do particular things.
Maybe there should be a democratic vote about proposed changes? While
this cannot be perfect, it probably would be much better than allowing
everyone with knowledge of C and SVN to change the language.
> Besides, in the future, if there are
> any bugs in get() or value(), we'll have someone to turn to,
> other than me.
I can understand, that you appreciate it when Euphoria is more and more
taken over by the community. And of course this is a "natural" process
after something has been made open source.
However, in the past another advantage of Euphoria has been its
reliability. Every change introduces the risk of new bugs. So changes
that have almost no benefit better shouldn't be made.
As far as I can see, _currently_ get() and value() are not buggy ...
So maybe you can firstly release a bugfix release of Eu 3.1, without
any other changes? This would be important in order to provide a stable
version which we can use for building reliable programs. I would
appreciate it _very_ much.
Regards,
Juergen
17. Re: Source changes
Derek Parnell wrote:
>
> Salix wrote:
> >
> > I welcome the proposed routines as I regularly use similar ones.
> > The only thing I am opposed to is the CamelCase routine names.
> > Euphoria (in general) doesn't use it.
>
> You're correct. To be consistent the underscore names would be better.
>
> > Could you write a few more words about the following ones?
> > The most problems I have with these conversions. (Specially
> > the lack of date and time functions.)
>
> The commonly used date format is {YYYY,MM,DD, ...} but the Epoch form is also
> used. There are at least two good date-time libraries in the User
> Contributions
> section so I'd suggest that we combine the good aspects of those into a single
> officially-supported library.
>
> I imagine that the formatting codes for format_date() and format_time() will
> be along the lines of the unix date command.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
What you say is true for UK/US aligned countries. Most Latin countries (France,
Spain, Italy...) use DD-MM-YY or -YYYY format. And if I remember correctly, Japan
uses another specific format.
As a result, locale-dependent routines are needed. Problem is, how will they
behave under DOS, where I am not sure that locales make sense at all?
Generally speaking, I fully approve the addition of one or two more include
files related to text<->number conversion and date/time formatting. Not that I
use them a lot, but they are useful to enough people around.
Hurray!
CChris
18. Re: Source changes
Derek Parnell wrote:
> CChris wrote:
>
> > 1/ some people, perhaps many of them, are looking for a function that
> > converts
> > a string into a numerical value and hardly anything else. Derek Parnell
> > hinted
> > that he would submit a tidied up version of w32to_number().
> > 2/ If I understand well what has been said, many people will switch to that
> > function and leave value() alone anyway. This will certainly decrease the
> > amount
> > of possible groaning, as w32to_number(), or whatever it will be eventually
> > named,
> > will be "simpler" (= return less data? not sure, but oh well).
>
> I've started the process. I'm packaging this function plus a few others into
> a new library, whose purpose will be to contain text conversion routines. Thus
> a new library called "convtext.e" will be added to the Euphoria include
> folder.
> It will contain a set of related functions that convert text strings into
> numbers
> and visa versa.
>
> -- Proposed Routines --
> This set will attempt to convert the text to the requested format, but if
> they are unable to they do not fail, instead they return zero.
>
> toInteger(sequence TextIn) -- converts the text to an integer.
> toNumber(sequence TextIn) -- converts the text to an integer or atom as
> -- appropriate.
> toDigits(sequence TextIn) -- converts the text to an integer or atom as
> -- appropriate, but disregards all non-digits
> -- except the first decimal-separator.
> toBase(sequence TextIn, integer Base) -- converts the text to an
> -- integer or atom as appropriate,
> -- but disregards all non-digits as
> -- defined by the 'number-base'
> -- supplied.
>
>
> This set will attempt to convert the text to the requested format, but if
> they are unable to they do not fail, instead they return a sequence containing
> the position in the input where conversion stopped, and the result of the
> conversion
> as at that point.
>
> CInt(sequence TextIn) -- converts the text to an integer.
> CNum(sequence TextIn) -- converts the text to an integer or atom as
> -- appropriate.
>
> This set will test the text for conversion but will not actually convert it,
> instead they return a true/false value.
>
> isInteger(sequence TextIn) -- checks that the text could be converted
> -- to an integer
> isNumber(sequence TextIn) -- checks that the text could be converted
> -- to an integer or atom
>
> Those routines will allow for decimal-separators, number-grouping, leading
> sign
> (+/-) or trailing sign, currency symbol, scientific notation, number-bases
> from
> 2 to 94, parenthetical negatives, and scaling symbols.
>
> The user will be able to set the values for decimal-separator, number-groups,
> currency
> symbols, and scaling symbols. By default they will be set to ".", ",_ ",
> "$¢£¤¥₣₤₧₪₫€",
> and "%‰" (unicode only).
>
> This next function takes a sequence of text strings and returns the same
> sequence
> but with as many strings as possible converted to numbers.
>
> makeNumbers(sequence RecordData)
>
> e.g. makeNumbers({"Derek", "Parnell", "555 7748", "19", "North Road"})
> would return
> {"Derek", "Parnell", 5557748, 19, "North Road"}
>
>
> This set of routines converts a number to a text string, some using locale
> settings.
>
> StringInt( integer Data )
> StringNumber( atom Data )
> StringFormat( atom Data, sequence Format)
> DateFormat ( sequence Data, sequence Format)
> TimeFormat ( atom Data, sequence Format)
> CurrencyFormat (atom Data)
>
> This library can also be used for other text conversions as the need arises.
>
>
> Comments please...
I think it would be best to send this library to the User Contributions page.
After some months, when people use the code and like the code, and have given
some micro bucks to it, it could be considered to put this lib into the
standard release of Euphoria.
Regards,
Juergen
19. Re: Source changes
Juergen Luethje wrote:
>
> Robert Craig wrote:
>
> > Juergen Luethje wrote:
>
> >> CChris wrote:
> >>
> >>> A few hours ago, I checked in the changes related to value() and get(), so
> >>> that
> >>> they both return 4 element sequences. I didn't test the generated docs.
> >>
> >> <snip>
> >>
> >> Rob,
> >>
> >> please do not put these changes into the next Euphoria release.
> >
> > I can understand your concerns about keeping things
> > simple, but I'm not going to veto this change. I doubt that
> > it will cause much, if any, code to break.
>
> Backwards compatibility is not my main concern. However, for the sake of
> completeness: The proposed change will cause code to break such as
> }}}
<eucode>
> if equal(value(s), {GET_SUCCESS,a}) then
> </eucode>
{{{
>
Would you have thought about it without my mentioning it? <smile/>
> > Christian should listen
> > carefully to the arguments of others on this forum, but if he
> > still thinks it's a good idea, then it's OK with me if he proceeds.
> > People who take the time to learn SVN, and who do the actual
> > programming work, should be given the benefit of the doubt
> > on small changes like this.
>
> Sorry, I disagree.
> While knowledge of C and SVN is necessary to make changes to the
> language, this does not mean that everyone who meets these requirements
> will make sensible changes.
True.
> Sometimes (often?) less is more, and
Only sometimes. More functionality or flexibility is always good.
> sometimes (often?) it is better _not_ do do particular things.
>
> Maybe there should be a democratic vote about proposed changes? While
> this cannot be perfect, it probably would be much better than allowing
> everyone with knowledge of C and SVN to change the language.
>
I fully agree. We just need a polling system. Forum software often offer such
facilities.
> > Besides, in the future, if there are
> > any bugs in get() or value(), we'll have someone to turn to,
> > other than me.
>
> I can understand, that you appreciate it when Euphoria is more and more
> taken over by the community. And of course this is a "natural" process
> after something has been made open source.
>
> However, in the past another advantage of Euphoria has been its
> reliability.
At the cost of an extremely slow evolution pace, the price of which we all pay
and about which many people have complained before leaving.
As far as strong, uniform quality control is concerned, I already posted about
it being necessary, and Derek appeared interested in slowly building a strong
test suite, with community contributions. He has the useful experience of the
D-stress project to back up his claim, so I think your rightful concern will be
properly taken care of. We all should help.
> Every change introduces the risk of new bugs.
Some people may have said this as early as when cooking was invented. Some bugs,
called bush fires, were quite lethal indeed.
> So changes
> that have almost no benefit better shouldn't be made.
This is logically true, but it all depends on how you evaluate the benefits.
> As far as I can see, _currently_ get() and value() are not buggy ...
>
They are, please read http://www.openeuphoria.org/EUforum/m14649.html . I have
failed to read your comments on this post so far.
> So maybe you can firstly release a bugfix release of Eu 3.1, without
> any other changes? This would be important in order to provide a stable
> version which we can use for building reliable programs. I would
> appreciate it _very_ much.
Probably a good idea.
>
> Regards,
> Juergen
CChris
20. Re: Source changes
Juergen Luethje wrote:
> Sorry, I disagree.
> While knowledge of C and SVN is necessary to make changes to the
> language,
I suggested that developers should be able to build on at least
one platform (using a C compiler), but actually, since most
Euphoria libraries are written in pure Euphoria, and the
front-end is written in pure Euphoria, I would accept
new developers who do not know C or have a C compiler set up
on their machines, as long as they are just changing Euphoria code.
They would have to test their changes by running eu.ex
(slow Euphoria-coded execute.e as back-end) or int.ex
(newly-available in 3.1, front-end can be interpreted but
calls fast C-coded back-end via machine_proc()).
SVN is just a tool for copying source files from a common
repository, and checking them in again, when you want to
officially change them. It has features that help you to keep
track of what you have changed, and resolve conflicts with
others who (rarely) may happen to be working on the
same file at the same time. I think anyone could learn the
basics of SVN in an hour or two. Like most mature tools,
it has lots of advanced features that are rarely used by beginners.
TortoiseSVN for Windows makes things particularly easy.
You just right-click on a file and it gives you menu of things
that you can do with that file, such as check it in (commit it).
> this does not mean that everyone who meets these requirements
> will make sensible changes. Sometimes (often?) less is more, and
> sometimes (often?) it is better _not_ do do particular things.
Very true.
> Maybe there should be a democratic vote about proposed changes? While
> this cannot be perfect, it probably would be much better than allowing
> everyone with knowledge of C and SVN to change the language.
We may eventually need a formal voting system, but at the
moment we are still "playing it by ear", trying to get
an informal, rough consensus on any changes.
> > Besides, in the future, if there are
> > any bugs in get() or value(), we'll have someone to turn to,
> > other than me.
>
> I can understand, that you appreciate it when Euphoria is more and more
> taken over by the community. And of course this is a "natural" process
> after something has been made open source.
Having recently read "Wikinomics: How Mass Collaboration Changes Everything",
http://www.amazon.com/Wikinomics-Mass-Collaboration-Changes-Everything/dp/1591841380/ref=pd_bbs_sr_1/103-7756507-1669435?ie=UTF8&s=books&qid=1183395126&sr=8-1
I am optimistic that open source is the right way to go.
Although bugs will be introduced at a higher rate, (especially as
developers are first exposed to my complicated code),
I think they will be fixed at a much higher rate than before.
Think about the recent find_from() bug that you helped resolve:
Someone detects it, other people come up with simpler examples,
someone else goes into the C code and suggests a fix. By the time the
developer wakes up in the morning, most of his work has been done!
Then someone else (me) eventually re-releases it.
Many hands make light (and fast) work!
> However, in the past another advantage of Euphoria has been its
> reliability. Every change introduces the risk of new bugs. So changes
> that have almost no benefit better shouldn't be made.
> As far as I can see, _currently_ get() and value() are not buggy ...
>
> So maybe you can firstly release a bugfix release of Eu 3.1, without
> any other changes? This would be important in order to provide a stable
> version which we can use for building reliable programs. I would
> appreciate it _very_ much.
I'd like to do a 3.1.1 release within a few weeks, rather
than a few months (like the past few releases).
A major advantage of SVN is the ability to look at diffs
in source files, identify the causes of bugs,
and undo changes that we decide are bad ones.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
21. Re: Source changes
- Posted by Juergen Luethje <j.lue at gmx.d?>
Jul 02, 2007
-
Last edited Jul 03, 2007
Robert Craig wrote:
> Juergen Luethje wrote:
<snip>
>> So maybe you can firstly release a bugfix release of Eu 3.1, without
>> any other changes? This would be important in order to provide a stable
>> version which we can use for building reliable programs. I would
>> appreciate it _very_ much.
>
> I'd like to do a 3.1.1 release within a few weeks, rather
> than a few months (like the past few releases).
>
> A major advantage of SVN is the ability to look at diffs
> in source files, identify the causes of bugs,
> and undo changes that we decide are bad ones.
What I wanted to ask for is:
Could you please in version 3.1.1 only include the fixes of
the bugs which are in version 3.1? I think this is mainly the
bug in find_from() and the memory leak on Linux.
And if you actually think the changes by CChris should be put
into Euphoria, couöd you do so in a later version, but not in
Eu 3.1.1, please?
Doing so would reduce the risk of introducing new bugs in Eu 3.1.1,
and so increase the chance that it will be a stable release.
I just need a stable release for writing programs that are used by
more than 10 000 people. The most recent stable release is 3.0.2,
but I would prefer a stable release that contains find_from() and
match_from().
Pleeeease.
Regards,
Juergen
22. Re: Source changes
- Posted by Juergen Luethje <j.lue at gmx.d?>
Jul 02, 2007
-
Last edited Jul 03, 2007
CChris wrote:
> Juergen Luethje wrote:
<snip>
>> As far as I can see, _currently_ get() and value() are not buggy ...
>>
>
> They are, please read <a
> href="http://www.openeuphoria.org/EUforum/m14649.html">http://www.openeuphoria.org/EUforum/m14649.html</a>
> . I have failed to read your comments on this post so far.
I'm so sorry that I didn't write a comment on each of your posts.
What you mention in the concerning post is a glitch in the documentation,
not a bug in the code.
Regards,
Juergen
23. Re: Source changes
- Posted by Matt Lewis <matthewwalkerlewis at gma?l.com>
Jul 02, 2007
-
Last edited Jul 03, 2007
Juergen Luethje wrote:
>
> What I wanted to ask for is:
> Could you please in version 3.1.1 only include the fixes of
> the bugs which are in version 3.1? I think this is mainly the
> bug in find_from() and the memory leak on Linux.
>
I agree with you, and fortunately, it's fairly easy to to. I haven't had
a chance yet to take a look at the memory leak issue (been *really* busy
lately) I'll start a branch (if no one beats me to it) for 3.1.1, and port
over the find_from fix.
Matt
24. Re: Source changes
Pete Lomax wrote:
>
> Derek Parnell wrote:
> >
> > Comments please...
> >
> >a new library called "convtext.e" will be added to Euphoria include folder.
> Good. A new include file means less impact on legacy code.
That's what I was thinking too.
> The idea of a user-definable callback, like walk_dir()/default_dir() in
> file.e,
> still appeals to me as you can make it dead easy for newbies but still have
> fine control for advanced coders.
>
> Did you have any comments on my proposed changes to get.e?
> <a target=_top
> href="http://palacebuilders.pwp.blueyonder.co.uk/pc.htm">http://palacebuilders.pwp.blueyonder.co.uk/pc.htm</a>
> I accept the above is not going to be used, and that instead of passing a
> routine_id
> on every call, an optional set() at the start would be better.
I'm not sure what this idea gains us. What sort of things would the callback
routine do? The normal reason for callbacks is to implement an iterator, which is
called for each selected element of some set, or to modify/approve of some
activity done by the calling routine. Your code in get2.e doesn't allow for stuff
done by the callback to be passed back to the calling program so I'm not sure
what you see such callbacks doing.
> >
> > -- Proposed Routines --
> > This set will attempt to convert the text to the requested format, but if
> > they are unable to they do not fail, instead they return zero.
> >
> > toInteger(sequence TextIn) -- converts the text to an integer.
> > toNumber(sequence TextIn) -- converts the text to an integer or atom as
> > -- appropriate.
> > toDigits(sequence TextIn) -- converts the text to an integer or atom as
> > -- appropriate, but disregards all non-digits
> > -- except the first decimal-separator.
> > toBase(sequence TextIn, integer Base) -- converts the text to an
> > -- integer or atom as appropriate,
> > -- but disregards all non-digits as
> > -- defined by the 'number-base'
> > -- supplied.
> Just as an idea, I wonder:
> text_to_data(INTEGER,xxx)
> text_to_data(ATOM,xxx)
> text_to_data(DIGITS,xxx)
> text_to_data({BASE,12},xxx)
> Extendable with strings and sequences and dates and times and wotnot that way.
Hmmm... worth considering ... there might be some performance issues but I'll
give it serious thinking time.
> This is also very value()-sided, no equivalent get() routines.
Yeah, that's deliberate. This proposed library is not an I/O library but a text
conversion library. If you want the equivalent 'gets', then you will need to code
the shim.
line = gets(filehandle)
result = to_number(line)
or whatever ...
>
> > Those routines will allow for decimal-separators, number-grouping,
> I got lost here. I could't work out if you meant all the routines mentioned
> in the post, the ones just above, or the ones after that point.
Ok, my bad message writing skills are evident here. <G>
I meant all routines that parse text to find numbers will use algorithms that
take into consideration such things as decimal-separators, ... etc ...
> Actually, I
> think I'd like to see RDS-style docs for these new routines up front.
Absolutely! I'm writing those docs/specs now and will publish them for comment
before submitting library code.
> > StringInt( integer Data )
result = sprintf("%d", Data)
vs
result = StringInt(Data)
> > StringNumber( atom Data )
if integer(Data) then
result = sprintf("%d", Data)
else
result = trim(sprintf("%15.15f", Data))
end if
vs
result = StringNumber(Data)
> > StringFormat( atom Data, sequence Format)
result = StringFormat(Data, {"$##,###,##9.99", "$##,###,##9.99CR", "#"})
-- This allows a different pattern for +ve, -ve and zero values.
-- The actual currency, grouping, decimal, and credit symbols
-- will be based on the locale data supplied.
-- For more examples, look at the formatting available in MS-Excel.
Also things like user-named formatting strings will be available ...
define_formatter("StdCurrency", {"$##,###,##9.99", -- +ve
"$##,###,##9.99CR", -- -ve
"#" -- zero
})
result1 = StringFormat(Data1, {"&StdCurrency"})
result2 = StringFormat(Data2, {"&StdCurrency"})
result3 = StringFormat(Data3, {"&StdCurrency"})
result4 = StringFormat(Data4, {"&StdCurrency"})
also this can be done as
result = StringFormat({Data1, Data2, Data3, Data4},
{"&StdCurrency"})
-- giving a 4-element sequence of formatted numbers.
> Without examples I see no gain over sprint(f).
That enough for now?
> > DateFormat ( sequence Data, sequence Format)
> > TimeFormat ( atom Data, sequence Format)
> > CurrencyFormat (atom Data)
>
> I would, for example, hope to see in RDS-style docs that DateFormat etc should
> only be used for display and reporting purposes; saving data to file should
> use the rawest possible format, eg {2007,7,2} not "2nd July 2007", otherwise
> a user in a different locale may not be able to read the data.
Yes, but that is not a fault of a library. <G>
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
25. Re: Source changes
Alan Oxley wrote:
>
> Ok Derek,
> So if your "to_xxxx" routines only return data,
> and the "conv_xxxx" also indicate conversion success,
> I guess I will be my usual pedantic self ;)
> and always call conv_xxxx !
Me too, most likely. But Q&D program still exists too.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
26. Re: Source changes
For those concerned with new bugs, or the simply curious:
The modified get.e where get() and value() return length 4 sequences is
available here:
http://oedoc.free.fr/value_get/get.e
There is also a version which not only returns extra information, but also fixes
a documented quirk of get(). It requires a modified interpreter. exw.exe (sorry,
don't know how to build exu, advice appreciated) and yet another get.e are
available there:
http://odeoc.free.fr/get_fixed/
Come on, folks. Instead of fearing change and bugs, think positive, go
experiment, get the hang of it, benchmark and chase bugs. That's how we'll get a
better language.
As for the get_fixed folder, those who can build interpreters and are willing to
test for performance penalty (couldnt find any compiling with OW1.6 under WinXP)
can check out the cchris_get branch on svn and play.
CChris
27. Re: Source changes
Juergen Luethje wrote:
>
> Robert Craig wrote:
>
> > Juergen Luethje wrote:
>
> >> CChris wrote:
> >>
> >>> A few hours ago, I checked in the changes related to value() and get(), so
> >>> that
> >>> they both return 4 element sequences. I didn't test the generated docs.
> >>
> >> <snip>
> >>
> >> Rob,
> >>
> >> please do not put these changes into the next Euphoria release.
> >
> > I can understand your concerns about keeping things
> > simple, but I'm not going to veto this change. I doubt that
> > it will cause much, if any, code to break.
>
> Backwards compatibility is not my main concern. However, for the sake of
> completeness: The proposed change will cause code to break such as
> }}}
<eucode>
> if equal(value(s), {GET_SUCCESS,a}) then
> </eucode>
{{{
I understand your concern. However, because of the very nature of Euphoria's
sequence paradigm, Euphoria coders must never assume that the length of a
returned sequence will be anything specific. A better (?) coding for this
construct might be
if begins(value(s), {GET_SUCCESS,a}) then
(That reminds me, I should submit my begins()/ends() functions to the standard
library too. )
global function begins(sequence s, object b)
if length(s) = 0 then
return 0
end if
if atom(b) then
return (s[1] = b)
end if
if length(b) = 0 then
return 0
end if
if length(b) > length(s) then
return 0
end if
return equal(s[1..length(b)], b)
end function
global function ends(sequence s, object b)
if length(s) = 0 then
return 0
end if
if atom(b) then
return (s[$] = b)
end if
if length(b) = 0 then
return 0
end if
if length(b) > length(s) then
return 0
end if
return equal(s[length(s) - length(b) + 1 .. $], b)
end function
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
28. Re: Source changes
CChris wrote:
>
> Derek Parnell wrote:
> > The commonly used date format is {YYYY,MM,DD, ...} but the Epoch form is
> > also
> > used. There are at least two good date-time libraries in the User
> > Contributions
> > section so I'd suggest that we combine the good aspects of those into a
> > single
> > officially-supported library.
> What you say is true for UK/US aligned countries. Most Latin countries
> (France,
> Spain, Italy...) use DD-MM-YY or -YYYY format. And if I remember correctly,
> Japan uses another specific format.
I suspect you have misread what I said above. The date format I described is the
INTERNAL one and not the one formatted for display. I know the locale issues very
well as I have to deal with the US-Centric world far too often.
Most countries use DD-MM-YYYY, Japan mostly uses YYYY-MM-DD, and the U.S. uses
MM-DD-YYYY, plus there are other variations.
> As a result, locale-dependent routines are needed. Problem is, how will they
> behave under DOS, where I am not sure that locales make sense at all?
I had in mind that the applications using my library would specify the locale
elements (once) at run time and I wouldn't try to get them from the operating
system. I'd leave that task to the application.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
29. Re: Source changes
Juergen Luethje wrote:
> I think it would be best to send this library to the User Contributions page.
> After some months, when people use the code and like the code, and have given
> some micro bucks to it, it could be considered to put this lib into the
> standard release of Euphoria.
Fair enough, but I'm not going to do that. I'll submit it for peer review and
after a few corrections/improvements I'll submit it to SourceForge and let Robert
make the call.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
30. Re: Source changes
Salix wrote:
>
> I welcome the proposed routines as I regularly use similar ones.
> The only thing I am opposed to is the CamelCase routine names.
> Euphoria (in general) doesn't use it. See:
>
I LIKE CamelCase routine names!! :)
(easier to type)
Dan Moyer
31. Re: Source changes
Derek Parnell wrote:
>
> I'm not sure what this idea gains us. What sort of things would the
> callback routine do?
Centralised error handling (of the abort variety) mainly. See
http://www.openeuphoria.org/EUforum/m14657.html
> Absolutely! I'm writing those docs/specs now and will publish them for
> comment before submitting library code.
Good-oh.
> That enough for now?
Yup.
Regards,
Pete
32. Re: Source changes
Derek Parnell wrote:
> Juergen Luethje wrote:
> >
> > Robert Craig wrote:
> >
> > > Juergen Luethje wrote:
> >
> > >> CChris wrote:
> > >>
> > >>> A few hours ago, I checked in the changes related to value() and get(),
> > >>> so
> that</font></i>
> > >>> they both return 4 element sequences. I didn't test the generated docs.
> > >>
> > >> <snip>
> > >>
> > >> Rob,
> > >>
> > >> please do not put these changes into the next Euphoria release.
> > >
> > > I can understand your concerns about keeping things
> > > simple, but I'm not going to veto this change. I doubt that
> > > it will cause much, if any, code to break.
> >
> > Backwards compatibility is not my main concern. However, for the sake of
> > completeness: The proposed change will cause code to break such as
> > }}}
<eucode>
> > if equal(value(s), {GET_SUCCESS,a}) then
> > </eucode>
{{{
>
> I understand your concern.
Since Rob had written:
"I doubt that it will cause much, if any, code to break.",
I mainly added that comment for the sake of completeness
("for the records" so to say).
> However, because of the very nature of Euphoria's
> sequence paradigm, Euphoria coders must never assume that the length of a
> returned
> sequence will be anything specific.
Huuu?
We must not assume that things work according to the documentation?
<snip>
Regards,
Juergen
33. Re: Source changes
Derek Parnell wrote:
> Juergen Luethje wrote:
>
> > I think it would be best to send this library to the User Contributions
> > page.
> > After some months, when people use the code and like the code, and have
> > given
> > some micro bucks to it, it could be considered to put this lib into the
> > standard release of Euphoria.
>
> Fair enough, but I'm not going to do that. I'll submit it for peer review and
> after a few corrections/improvements I'll submit it to SourceForge and let
> Robert
> make the call.
I naively had assumed that "Open Source" means, besides other things, that
such a decision would be made democratically by all members of the Euphoria
community.
Regards,
Juergen
34. Re: Source changes
Robert Craig wrote:
> Juergen Luethje wrote:
<snip>
>> Maybe there should be a democratic vote about proposed changes? While
>> this cannot be perfect, it probably would be much better than allowing
>> everyone with knowledge of C and SVN to change the language.
>
> We may eventually need a formal voting system, but at the
> moment we are still "playing it by ear", trying to get
> an informal, rough consensus on any changes.
I think we should have a formal voting system as soon as possible.
Regards,
Juergen
35. Re: Source changes
Juergen Luethje wrote:
>
> Derek Parnell wrote:
>
> > Juergen Luethje wrote:
> >
> > > I think it would be best to send this library to the User Contributions
> > > page.
> > > After some months, when people use the code and like the code, and have
> > > given
> > > some micro bucks to it, it could be considered to put this lib into the
> > > standard release of Euphoria.
> >
> > Fair enough, but I'm not going to do that. I'll submit it for peer review
> > and
> > after a few corrections/improvements I'll submit it to SourceForge and let
> > Robert
> > make the call.
>
> I naively had assumed that "Open Source" means, besides other things, that
> such a decision would be made democratically by all members of the Euphoria
>
> community.
I don't have any objection to including it in the standard distribution (so that
would make it 2 all).
While we're at it I also agree with Derek's suggestion of an improved/combined
Date/Time include.
Gary
36. Re: Source changes
CChris wrote:
> Come on, folks. Instead of fearing change and bugs, think positive,
> go experiment, get the hang of it,
You are sounding like a politician who does not know what he's
talking about anyway. The election campaign in France is over.
BTW: You can keep cool. Rob wrote that he will not veto your changes.
Regards,
Juergen
37. Re: Source changes
Gary Shingles wrote:
>
> Juergen Luethje wrote:
> >
> > Derek Parnell wrote:
> >
> > > Juergen Luethje wrote:
> > >
> > > > I think it would be best to send this library to the User Contributions
> > > > page.
> > > > After some months, when people use the code and like the code, and have
> > > > given
> > > > some micro bucks to it, it could be considered to put this lib into the
> > > > standard release of Euphoria.
> > >
> > > Fair enough, but I'm not going to do that. I'll submit it for peer review
> > > and
> > > after a few corrections/improvements I'll submit it to SourceForge and let
> > > Robert
> > > make the call.
> >
> > I naively had assumed that "Open Source" means, besides other things, that
> > such a decision would be made democratically by all members of the Euphoria
> >
> > community.
>
> I don't have any objection to including it in the standard distribution (so
> that would make it 2 all).
IMHO there should be a formal voting system ASAP.
Regards,
Juergen
>
> While we're at it I also agree with Derek's suggestion of an improved/combined
> Date/Time include.
>
> Gary
38. Re: Source changes
Derek Parnell wrote:
<snip>
> I suspect you have misread what I said above. The date format I described is
> the INTERNAL one and not the one formatted for display. I know the locale
> issues
> very well as I have to deal with the US-Centric world far too often.
>
> Most countries use DD-MM-YYYY, Japan mostly uses YYYY-MM-DD, and the U.S. uses
> MM-DD-YYYY, plus there are other variations.
BTW: The international ISO standard format is YYYY-MM-DD.
<snip>
Regards,
Juergen
39. Re: Source changes
Juergen Luethje wrote:
>
> Gary Shingles wrote:
> >
> > Juergen Luethje wrote:
> > >
> > > Derek Parnell wrote:
> > >
> > > > Juergen Luethje wrote:
> > > >
> > > > > I think it would be best to send this library to the User
> > > > > Contributions
> page.</font></i>
> > > > > After some months, when people use the code and like the code, and
> > > > > have
> given</font></i>
> > > > > some micro bucks to it, it could be considered to put this lib into
> > > > > the
> > > > > standard release of Euphoria.
> > > >
> > > > Fair enough, but I'm not going to do that. I'll submit it for peer
> > > > review and
> > > > after a few corrections/improvements I'll submit it to SourceForge and
> > > > let
> Robert</font></i>
> > > > make the call.
> > >
> > > I naively had assumed that "Open Source" means, besides other things, that
> > > such a decision would be made democratically by all members of the
> > > Euphoria
> > >
> > > community.
> >
> > I don't have any objection to including it in the standard distribution (so
> > that would make it 2 all).
>
> IMHO there should be a formal voting system ASAP.
The idea of voting sounds very democratic, however the way in which that voting
system plays a part in the process of developing Euphoria, I am afraid, might
become more bureaucratic than democratic.
Besides, with this issue (I actually forget whether it is over get, or Derek's
thing) what if you are correct and it should not be included, or done, but there
is a vote and it is included, or done... wouldn't you rather have the opportunity
to continue to discus something rather than having it all come to a final,
binding, vote?
If for example we did have a voting system for Euphoria "features", how would
you see that working? What would the process be?
Gary
40. Re: Source changes
Juergen Luethje wrote:
>
> Derek Parnell wrote:
> > However, because of the very nature of Euphoria's
> > sequence paradigm, Euphoria coders must never assume that the length of a
> > returned
> > sequence will be anything specific.
>
> Huuu?
> We must not assume that things work according to the documentation?
Of course you should. The documentation clearly states that the first two
elements returned contain those items you were testing for. It does not say that
this function will never in the future return additional values
So therefore one could code defensively and make sure you only check the first
two elements, but even that doesn't mean that future library changes will never
break your code.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
41. Re: Source changes
Juergen Luethje wrote:
>
> Derek Parnell wrote:
>
> > Juergen Luethje wrote:
> >
> > > I think it would be best to send this library to the User Contributions
> > > page.
> > > After some months, when people use the code and like the code, and have
> > > given
> > > some micro bucks to it, it could be considered to put this lib into the
> > > standard release of Euphoria.
> >
> > Fair enough, but I'm not going to do that. I'll submit it for peer review
> > and
> > after a few corrections/improvements I'll submit it to SourceForge and let
> > Robert
> > make the call.
>
> I naively had assumed that "Open Source" means, besides other things, that
> such a decision would be made democratically by all members of the Euphoria
> community.
What part of "peer review" and "SourceForge" made you think that this library
was not open source?
And since when has anything in Euphoria been democratically elected. Now if this
library was such that it was being forced on people; that they had to use it,
then may a 'popular' vote might be needed. But no one is forcing this library on
anyone. In fact, the only voting that will happen, and its very effective voting,
is whether or not people choose to use the library.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
42. Re: Source changes
Derek Parnell wrote:
>
> CChris wrote:
> >
> > Derek Parnell wrote:
> > > The commonly used date format is {YYYY,MM,DD, ...} but the Epoch form is
> > > also
> > > used. There are at least two good date-time libraries in the User
> > > Contributions
> > > section so I'd suggest that we combine the good aspects of those into a
> > > single
> > > officially-supported library.
>
> > What you say is true for UK/US aligned countries. Most Latin countries
> > (France,
> > Spain, Italy...) use DD-MM-YY or -YYYY format. And if I remember correctly,
> > Japan uses another specific format.
>
> I suspect you have misread what I said above. The date format I described is
> the INTERNAL one and not the one formatted for display. I know the locale
> issues
> very well as I have to deal with the US-Centric world far too often.
>
> Most countries use DD-MM-YYYY, Japan mostly uses YYYY-MM-DD, and the U.S. uses
> MM-DD-YYYY, plus there are other variations.
>
> > As a result, locale-dependent routines are needed. Problem is, how will they
> > behave under DOS, where I am not sure that locales make sense at all?
>
> I had in mind that the applications using my library would specify the locale
> elements (once) at run time and I wouldn't try to get them from the operating
> system. I'd leave that task to the application.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
That was not clear to me; now it is.
You can ask readily Windows about the user locale, and you can ask DOS for the
current country specific info thru int #21, AX=#3800, DS:DX->34 byte buffer.
The date format will be at offset 0 on return: 0 = USA mm dd yy,1 = Europe dd mm
yy
2 = Japan yy mm dd).
The buffer format is as follows, quoted from RBIL v61:
00h WORD date format (see #01398)
02h 5 BYTEs ASCIZ currency symbol string
07h 2 BYTEs ASCIZ thousands separator
09h 2 BYTEs ASCIZ decimal separator
0Bh 2 BYTEs ASCIZ date separator
0Dh 2 BYTEs ASCIZ time separator
0Fh BYTE currency format
bit 2 = set if currency symbol replaces decimal point
bit 1 = number of spaces between value and currency symbol
bit 0 = 0 if currency symbol precedes value
1 if currency symbol follows value
10h BYTE number of digits after decimal in currency
11h BYTE time format
bit 0 = 0 if 12-hour clock
1 if 24-hour clock
12h DWORD address of case map routine
(FAR CALL, AL = character to map to upper case [>= 80h])
16h 2 BYTEs ASCIZ data-list separator
18h 10 BYTEs reserved
For Linux, I don't know.
CChris
43. Re: Source changes
Gary Shingles wrote:
> Juergen Luethje wrote:
<snip>
>> IMHO there should be a formal voting system ASAP.
>
> The idea of voting sounds very democratic, however the way in which that
> voting
> system plays a part in the process of developing Euphoria, I am afraid, might
> become more bureaucratic than democratic.
Well said.
I also would appreciate it, if the system would be as unbureaucratic as
possible.
> Besides, with this issue (I actually forget whether it is over get, or Derek's
> thing)
Generally speaking, I'd like to have some kind of democratic voting on
changes in the front-end or the back-end as well as on changes in the
libraries coded in Euphoria that ship with the official release.
> what if you are correct and it should not be included, or done, but there
> is a vote and it is included, or done... wouldn't you rather have the
> opportunity
> to continue to discus something rather than having it all come to a final,
> binding,
> vote?
I'm not sure whether I do understand properly what you mean.
If there will be a change that I do not like, but for which there was a
democratic voting, then I'll have no problem to accept that change.
If there is a change that I do not like, and this change only happens
because someone who knows something about SVN and has some free time and
thinks it's a good idea to change the language according to his personal
preferences, then it might happen that I will not accept that change.
> If for example we did have a voting system for Euphoria "features", how would
> you see that working? What would the process be?
Unfortunately, I have no experience in this regard, and so I have more
questions than answers. However, as far as libraries coded in Euphoria are
concerned, we already have a working and unbureaucratic voting system:
the micro economy. So we should use it whenever possible.
Rob recently wrote that he had read a book with the title
"Wikinomics: How Mass Collaboration Changes Everything". Maybe in that
book there was something written about this topic? (Just a guess.)
I, personally, mainly felt that it is time now to start this discussion.
Regards,
Juergen
44. Re: Source changes
Regarding voting -- I don't mind a voting system but I still like the idea of
Rob (or some other well-respected member of the community) to have a veto option.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
45. Re: Source changes
Jason Gade wrote:
> Regarding voting -- I don't mind a voting system but I still like the idea of
> Rob (or some other well-respected member of the community) to have a veto
> option.
I like the idea concerning the veto option, too.
Regards,
Juergen
46. Re: Source changes
Derek Parnell wrote:
> Juergen Luethje wrote:
> >
> > Derek Parnell wrote:
> >
> > > Juergen Luethje wrote:
> > >
> > > > I think it would be best to send this library to the User Contributions
> > > > page.
> > > > After some months, when people use the code and like the code, and have
> > > > given
> > > > some micro bucks to it, it could be considered to put this lib into the
> > > > standard release of Euphoria.
> > >
> > > Fair enough, but I'm not going to do that. I'll submit it for peer review
> > > and
> > > after a few corrections/improvements I'll submit it to SourceForge and let
> > > Robert
> > > make the call.
> >
> > I naively had assumed that "Open Source" means, besides other things, that
> > such a decision would be made democratically by all members of the Euphoria
> > community.
>
> What part of "peer review" and "SourceForge" made you think that this library
> was not open source?
>
> And since when has anything in Euphoria been democratically elected. Now if
> this library was such that it was being forced on people; that they had to use
> it, then may a 'popular' vote might be needed. But no one is forcing this
> library
> on anyone. In fact, the only voting that will happen, and its very effective
> voting, is whether or not people choose to use the library.
Is it possible that you forgot some smileys?
I think when I'll reply seriously to this post, you might tell me that
I don't have a good sense of humor, no?
Regards,
Juergen
47. Re: Source changes
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > Regarding voting -- I don't mind a voting system but I still like the idea
> > of
> > Rob (or some other well-respected member of the community) to have a veto
> > option.
>
> I like the idea concerning the veto option, too.
>
So do I.
48. Re: Source changes
- Posted by Juergen Luethje <j.lue at gmx.?e>
Jul 03, 2007
-
Last edited Jul 04, 2007
Matt wrote:
> Juergen Luethje wrote:
>
>> What I wanted to ask for is:
>> Could you please in version 3.1.1 only include the fixes of
>> the bugs which are in version 3.1? I think this is mainly the
>> bug in find_from() and the memory leak on Linux.
>
> I agree with you, and fortunately, it's fairly easy to to. I haven't had
> a chance yet to take a look at the memory leak issue (been *really* busy
> lately)
You wrote that you are moving. Uuhh, this means a lot of work.
I hope things are fine.
> I'll start a branch (if no one beats me to it) for 3.1.1, and port
> over the find_from fix.
Thank you.
But I doubt that Rob will build a release that only contains these changes ...
So how can I get it?
Regards,
Juergen
49. Re: Source changes
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > I still like the idea of Rob (or some other well-respected member of
> > the community) to have a veto option.
>
> I like the idea concerning the veto option, too.
I was thinking along similar lines.
There probably *should* be a place where half-baked, undocumented, flakey and
experimental mods can be submitted, and equally some mechanism to stop such
ending up unintentionally/by default in the next formal release.
(I don't CVS/SVN, so if this is how it already works, pls ignore me.)
I thought about a using a sourceforge forum, but EuWiki seemed better: While
most discussion should remain on EUforum, set up "Intent to port" page(s), as a
place for anyone to post a "formal" (and carefully considered) veto. The purpose
is to maintain an apt summary, vs the 84,000 messages in Euforum, to control
migration of code from "bleeding edge" to "stable".
A veto can be logged by anyone and for any reason: inadequately documented, I
need a stable release, this code shows a bug, breaks this bit of legacy code,
etc. You must have a valid (and unique?) reason though, and of course you are
allowed to delete your veto if you change your mind.
However that would probably only work if there was a "bleeding edge" version,
ready-built, like the "overnight builds" I see elsewhere.
Obviously someone (Rob) needs final say-so over any protracted disagreement.
Regards,
Pete
50. Re: Source changes
Pete Lomax wrote:
>
> Juergen Luethje wrote:
> >
> > Jason Gade wrote:
> >
> > > I still like the idea of Rob (or some other well-respected member of
> > > the community) to have a veto option.
> >
> > I like the idea concerning the veto option, too.
>
> I was thinking along similar lines.
>
> There probably *should* be a place where half-baked, undocumented, flakey and
> experimental mods can be submitted, and equally some mechanism to stop such
> ending up unintentionally/by default in the next formal release.
> (I don't CVS/SVN, so if this is how it already works, pls ignore me.)
>
Indeed, SVN has a main development stream (the trunk), and branches, meant for
experimental stuff. All facilities to merge and roll back are available. Most of
the job can be done automatically, but clearly not all.
> I thought about a using a sourceforge forum, but EuWiki seemed better: While
> most discussion should remain on EUforum, set up "Intent to port" page(s), as
> a place for anyone to post a "formal" (and carefully considered) veto. The
> purpose
> is to maintain an apt summary, vs the 84,000 messages in Euforum, to control
> migration of code from "bleeding edge" to "stable".
>
> A veto can be logged by anyone and for any reason: inadequately documented,
> I need a stable release, this code shows a bug, breaks this bit of legacy
> code,
> etc. You must have a valid (and unique?) reason though, and of course you are
> allowed to delete your veto if you change your mind.
>
A flat, unmitigated no here.
Any looney tune could block anything for any kind of fancied up fallacy. There
had been someone like that in the past years, and there is another one these
days. There must be some veto power, but only aaavailable to those who are
responsible for public releases. Currently, that's Rob; in the future, this could
be a Wise Euphorians Council, whose initial layout and renewal system promise to
be a can of worms in practical terms.
Further, the reasons you give as examples are certainly not enough to justify
even a third of a veto. They certainly justify cooperative, incremental
amendment, not stifling conservatism.
> However that would probably only work if there was a "bleeding edge" version,
> ready-built, like the "overnight builds" I see elsewhere.
>
This is SVN's trunk. Perhaps all iterpreters are not built right away, but Rob
can do so, and anyone with enough different OSes and compilers can just as well,
running build.bat or buildu.
> Obviously someone (Rob) needs final say-so over any protracted disagreement.
>
> Regards,
> Pete
CChris
51. Re: Source changes
CChris wrote:
> Pete Lomax wrote:
<snip>
>> I thought about a using a sourceforge forum, but EuWiki seemed better: While
>> most discussion should remain on EUforum, set up "Intent to port" page(s), as
>> a place for anyone to post a "formal" (and carefully considered) veto. The
>> purpose
>> is to maintain an apt summary, vs the 84,000 messages in Euforum, to control
>> migration of code from "bleeding edge" to "stable".
>>
>> A veto can be logged by anyone and for any reason: inadequately documented,
>> I need a stable release, this code shows a bug, breaks this bit of legacy
>> code,
>> etc. You must have a valid (and unique?) reason though, and of course you are
>> allowed to delete your veto if you change your mind.
>>
>
> A flat, unmitigated no here.
> Any looney tune could block anything for any kind of fancied up fallacy. There
> had been someone like that in the past years, and there is another one these
> days.
This is not a flat "No" but just some more flat polemics from you.
Get your facts first, and then you can distort them as you please.
Regards,
Juergen
52. Re: Source changes
Pete Lomax wrote:
>
> Juergen Luethje wrote:
> >
> > Jason Gade wrote:
> >
> > > I still like the idea of Rob (or some other well-respected member of
> > > the community) to have a veto option.
> >
> > I like the idea concerning the veto option, too.
>
> I was thinking along similar lines.
>
> There probably *should* be a place where half-baked, undocumented, flakey and
> experimental mods can be submitted, and equally some mechanism to stop such
> ending up unintentionally/by default in the next formal release.
> (I don't CVS/SVN, so if this is how it already works, pls ignore me.)
>
> I thought about a using a sourceforge forum, but EuWiki seemed better: While
> most discussion should remain on EUforum, set up "Intent to port" page(s), as
> a place for anyone to post a "formal" (and carefully considered) veto. The
> purpose
> is to maintain an apt summary, vs the 84,000 messages in Euforum, to control
> migration of code from "bleeding edge" to "stable".
>
> A veto can be logged by anyone and for any reason: inadequately documented,
> I need a stable release, this code shows a bug, breaks this bit of legacy
> code,
> etc. You must have a valid (and unique?) reason though, and of course you are
> allowed to delete your veto if you change your mind.
>
> However that would probably only work if there was a "bleeding edge" version,
> ready-built, like the "overnight builds" I see elsewhere.
>
> Obviously someone (Rob) needs final say-so over any protracted disagreement.
>
> Regards,
> Pete
I agree !
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
53. Re: Source changes
CChris wrote:
>
> A flat, unmitigated no here.
> Any looney tune could block anything for any kind of fancied up fallacy.
Do you think that every idea that you have is perfect and beyond veto ?
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
54. Re: Source changes
I've been very buisy lately, but only after skimming this thread there seems to
be only alot of political gargen here, what is this thread actualy about?
55. Re: Source changes
Bernie Ryan wrote:
>
> CChris wrote:
> >
> > A flat, unmitigated no here.
> > Any looney tune could block anything for any kind of fancied up fallacy.
>
> Do you think that every idea that you have is perfect
No.
> and beyond veto ?
Neither, just saying that a veto is a very powerful weapon and that the fewer
people have it, the better. Many ideas only need improvements, not a veto, and a
dynamic, constructive community is usually a good source of them.
You should perhaps visit other language forums/lists to get the idea.
The above proposal implies that, to allow something being done, no one should
disagree - otherwise there will be a veto. This amounts to total immobility, as
there will always be someone against any given item/feature/idea if only for the
sake of it, as repeatedly seen on this list for years. Which has proven harmful
in countless contexts, Eu being just one of them.
CChris
>
> Bernie
>
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
56. Re: Source changes
- Posted by Gary Shingles <eu at 531pi.co?nz>
Jul 04, 2007
-
Last edited Jul 05, 2007
CChris wrote:
> Neither, just saying that a veto is a very powerful weapon and that the fewer
> people have it, the better. Many ideas only need improvements, not a veto, and
> a dynamic, constructive community is usually a good source of them.
> You should perhaps visit other language forums/lists to get the idea.
I think lodging 'objections' to a proposed change with good documentation is
healthy. Then perhaps rationalising the objections with further discussion
and/or voting. Wiki-style is good, keeps everything together.
Ultimately, if someone wants to go off and code something that is useful to them
in their mind, the law of averages holds that it will be useful to someone else.
If it means those people have to fork off, so to speak, then wouldn't it make
sense to use the same code base and develop forks side by side, such that the
trunk is the official interpreter and you have e.g. a candidate branch, russian
branch, then a "newphoria" branch, etc etc. The forks could be released and
supported via separate websites/forums etc but still benefit from new
developments on the trunk, and possibly vice-versa creating a whole slew of
'euphoric' languages.
Gary
57. Re: Source changes
Gary Shingles wrote:
>
> I think lodging 'objections' to a proposed change with good documentation
> is healthy. Then perhaps rationalising the objections with further
> discussion and/or voting. Wiki-style is good, keeps everything together.
>
Of course, 'objection' is a far better word to use than 'veto' and probably
closer to what I really meant.
CChris wrote:
>Any looney tune could block anything for any kind of fancied up fallacy.
If you replace 'block' with 'delay', then yes, absolutely. Just as 'the boy who
cried wolf', anyone objecting excessively will quickly get ignored.
> a Wise Euphorians Council
Looking at the current list of 6 developers on sourceforge, I would have no
objection to a majority vote of them being final arbiter of any disputes.
>Further, the reasons you give as examples are certainly not enough to
>justify even a third of a veto. They certainly justify cooperative,
>incremental amendment, not stifling conservatism.
How about shoving a pile of untested mods into file i/o that Rob had just said
no to? The less said about my feelings on that the better.
Anyway, by veto, I meant the 'next weekend' part of an announcement "Barring
objections I will port these changes to the main trunk next weekend". Any
disagreement should be resolved before the changes are applied.
>Perhaps all iterpreters are not built right away, but Rob can do so,
On behalf of Rob may I say that is quite rude of you even to suggest that!
>and anyone with enough different OSes and compilers can just as well,
>running build.bat or buildu.
So, if it is that easy, why is it not done yet? You may find more people willing
to test if they do not have to install a C compiler and SVN client.
Regards,
Pete
58. Re: Source changes
Gary Shingles wrote:
>
> CChris wrote:
> > Neither, just saying that a veto is a very powerful weapon and that the
> > fewer
> > people have it, the better. Many ideas only need improvements, not a veto,
> > and
> > a dynamic, constructive community is usually a good source of them.
> > You should perhaps visit other language forums/lists to get the idea.
>
> I think lodging 'objections' to a proposed change with good documentation is
> healthy. Then perhaps rationalising the objections with further discussion
> and/or voting. Wiki-style is good, keeps everything together.
>
> Ultimately, if someone wants to go off and code something that is useful to
> them in their mind, the law of averages holds that it will be useful to
> someone
> else. If it means those people have to fork off, so to speak, then wouldn't
> it make sense to use the same code base and develop forks side by side, such
> that the trunk is the official interpreter and you have e.g. a candidate
> branch,
> russian branch, then a "newphoria" branch, etc etc. The forks could be
> released
> and supported via separate websites/forums etc but still benefit from new
> developments
> on the trunk, and possibly vice-versa creating a whole slew of 'euphoric'
> languages.
>
> Gary
Although some details would have to be laid out in more detail, I'd certainly
agree in general terms with this scheme.
One of the issues is that, even if branches are available and hold such
development, allowing some healthy cross-breeding, people will need to:
* go take a look at the repository branches (Tortoise SVN is esay, at least the
GUI version or Windows. There are other clients, prehaps more convenient to us on
other platforms);
* build a relevant interpreter. That could be the roadblock, as the maintainer
of the branch may not have the tools to build all of ex.exe, exw.exe and exu, and
not everyone has a C compiler at the ready.
<side question>
How can I build exu under Windows?
</side quetion>
CChris
59. Re: Source changes
Snipped first sections, in agreement with them.
>
> >Further, the reasons you give as examples are certainly not enough to
> >justify even a third of a veto. They certainly justify cooperative,
> >incremental amendment, not stifling conservatism.
> How about shoving a pile of untested mods into file i/o that Rob had just said
> no to? The less said about my feelings on that the better.
>
That's why I maintain them in a separate branch, asking for tests/benchmarks
using compilers I don't have. No reports so far. If I had measured anything
wrong, I'd have removed it off shelf already. I don't know what, if any, proof
you have for the "untested" qualifier. Could you elaborate?
> Anyway, by veto, I meant the 'next weekend' part of an announcement "Barring
> objections I will port these changes to the main trunk next weekend". Any
> disagreement
> should be resolved before the changes are applied.
>
Ok. Is any disagreement eligible, or should it rely on provable facts (bug
report, benchmarking and such) to be considered? Guess I think the former isn't a
good idea, while the latter is plain common sense.
> >Perhaps all iterpreters are not built right away, but Rob can do so,
> On behalf of Rob may I say that is quite rude of you even to suggest that!
>
Uh?
Not my intent anyway. I think you lost me there.
The tool which is in the source directory, build.bat, stops whenever it doesn't
find any of the supported compilers. Rob stated that having all of them was not a
minimum requirement for committing tested code.
For instance, I repeatedly asked if it is possible, and how, to build exu under
Windows; I'd be happy to provide all three interpreters. What I was suggesting is
that Rob could help out with the *missing* interpreters.
Again, no rudeness implied or intended. If you have another replacement idea,
I'm a taker.
> >and anyone with enough different OSes and compilers can just as well,
> >running build.bat or buildu.
> So, if it is that easy, why is it not done yet? You may find more people
> willing
> to test if they do not have to install a C compiler and SVN client.
>
Let's be specific.
I posted my modified code on http://oedoc.free.fr in the value_get/ and
get_fixed/ directories. The former only holds get.e, because no modified
interpreter is required. Anyone can test.
The latter, corresponding to the branch I maintain, has get.e and a modified
exw.exe. I could add ex.exe, will do tonight. Now how do I add exu (see above)?
So far, people have to go to svn and build it if they want to test exu on that
branch. Otherwise, they don't need to do so and can just go ahead with the
available modified files for DOS/Windows.
What should I do next or instead?
There is an easy answer indeed: get another box and learn Linux. An easy one,
really? From recurring posts in this forum, I am not quite sure, it appears that
their dll hell is worse than Windows'. Of course, some Linux developers will have
the same kind of issues regarding DOS/Windows, I bet. And they may be able to
build only one interpreter.
I'm not even considering the problems that could arise from different behaviours
under various flavours of Unix around, if only because of my utter incompetence
in this respect.
CChris
> Regards,
> Pete
60. Re: Source changes
Juergen Luethje wrote:
>
> Matt wrote:
>
> You wrote that you are moving. Uuhh, this means a lot of work.
> I hope things are fine.
Yeah, just busy.
> > I'll start a branch (if no one beats me to it) for 3.1.1, and port
> > over the find_from fix.
>
> Thank you.
> But I doubt that Rob will build a release that only contains these changes ...
> So how can I get it?
Once I get it set up, there will be a "branch" in the svn repository from
which anyone can get the latest source. Basically, svn is based around
directories. We make a copy (in the repository) of the tagged 3.1 release
and call it 3.1.1. Then we merge all of the bugfixes into that branch of
code. Anyone with read access to the repository (which is anyone who can
manage to correctly type the url) can get that code.
Once we're 'happy' with it, we move it to a tag (which is just another
directory, which, by convention is read only and for historical purposes)
and we can make a release, even if it's only a zip that we just put up
on sourceforge.
Matt
61. Re: Source changes
Pete Lomax wrote:
>
>
> There probably *should* be a place where half-baked, undocumented, flakey and
> experimental mods can be submitted, and equally some mechanism to stop such
> ending up unintentionally/by default in the next formal release.
> (I don't CVS/SVN, so if this is how it already works, pls ignore me.)
There is a way to manage this using svn, by using a branch directory, and
doing experimental stuff there, to be later merged with the trunk. Complex
and/or many changes wouldn't be trivial to merge, but that's just the nature
of the beast.
Matt
62. Re: Source changes
CChris wrote:
>
> <side question>
> How can I build exu under Windows?
> </side quetion>
>
The easiest way is probably to install the VMWare player and a linux vm.
That's what I do (for FreeBSD, too).
Matt
63. Re: Source changes
Matt Lewis wrote:
>
> CChris wrote:
> >
> > <side question>
> > How can I build exu under Windows?
> > </side quetion>
> >
>
> The easiest way is probably to install the VMWare player and a linux vm.
> That's what I do (for FreeBSD, too).
>
> Matt
Thanks, I'll try that, waiting probably next weekend. I expect to get access to
some shell from which to run imakeu (say) and test the generated exu, am I right?
Or is it just opening a Unix-intended file with "linuvm.exe" or whatever it's
named?
Perhaps should there be a text file somewhere centralising this sort of
technical tips, in order to enable anyone in the community to contribute.
CChris
Note for Pete:
If this (or any other suggested scheme) works, then the paragraphs in my post
where I was talking about missing interpreters becomes pointless, except perhaps
concerning Linux developers and their ability to build ex[w].exe. I don't know
what they can or cannot do.
64. Re: Source changes
CChris wrote:
> <side question>
> How can I build exu under Windows?
> </side quetion>
You could install coLinux + your favourite distribution and have a native Linux
OS running side by side with Windows which would enable you to both compile and
test it (which is probably what you want to do). You can install X Windows with
a vnc based server so that you can test X apps as well.
Alternatively you could use Cygwin or MinGW to cross compile to elf-i386, but
then you still wouldn't be able to test it locally. And I don't know how much
support there is for cross compiling to ELF on Windows (though I'd suspect it's
possible).
Gary
65. Re: Source changes
CChris wrote:
>
> Matt Lewis wrote:
> >
> > CChris wrote:
> > >
> > > <side question>
> > > How can I build exu under Windows?
> > > </side quetion>
> > >
> >
> > The easiest way is probably to install the VMWare player and a linux vm.
> > That's what I do (for FreeBSD, too).
> >
> > Matt
>
> Thanks, I'll try that, waiting probably next weekend. I expect to get access
> to some shell from which to run imakeu (say) and test the generated exu, am
> I right? Or is it just opening a Unix-intended file with "linuvm.exe" or
> whatever
> it's named?
Basically, you install the VMWare player (free, but you have to register),
and then you need to download a VMWare appliance--many are available only
through bittorent. You open the appliance with the player, and then you
have a virtualized OS. I'd also recommend WinSCP for transferring files
between your host OS and the guest. You'll need a fair amount of free HD
space. The appliance is basically self contained, and are often several
GBs, especially after you've used them and put stuff in them.
I've been using the Ubuntu 7.04 (Feisty) and the FreeBSD 6.2 appliances.
Note that getting FreeBSD set up is a bit more work than Feisty. You
will probably want to reconfigure the display (the default is something
like 1024x480). Here's a link to a howto for changing this:
http://ubuntuforums.org/showthread.php?t=83973
You can try to use Rob's shell scripts, although I've never gotten them to
work properly for me, which is why I wrote the Makefiles. Take a look at
the file 'Makefile' in the source directory, but basically, you just go
to that directory and type 'make' at the prompt to make the interpreter.
Note that you may need to install some additional development packages from
your distribution's package manager (like for gpm). Many distros don't
have all of the header files, etc that you'll need installed by default.
It's not exactly trivial to get all set up to do development on linux,
especially if you don't have any linux experience, but it's definitely
a good learning experience, and shouldn't be too hard for most people,
once they start to figure out the linux way of doing things.
Matt
66. Re: Source changes
Gary Shingles wrote:
>
> CChris wrote:
> > <side question>
> > How can I build exu under Windows?
> > </side quetion>
>
> You could install coLinux + your favourite distribution and have a native
> Linux
> OS running side by side with Windows which would enable you to both compile
> and test it (which is probably what you want to do). You can install X
> Windows
> with a vnc based server so that you can test X apps as well.
>
> Alternatively you could use Cygwin or MinGW to cross compile to elf-i386, but
> then you still wouldn't be able to test it locally. And I don't know how much
> support there is for cross compiling to ELF on Windows (though I'd suspect
> it's
> possible).
>
> Gary
Thanks, and Matt as well. I may try the coLinux approach first.
If you hardly see me next week, suspect a computer messup, though I'll be able
to access the list from office (where I am right now).
CChris
67. Re: Source changes
Matt Lewis wrote:
<snip>
> Once I get it set up, there will be a "branch" in the svn repository from
> which anyone can get the latest source. Basically, svn is based around
> directories. We make a copy (in the repository) of the tagged 3.1 release
> and call it 3.1.1. Then we merge all of the bugfixes into that branch of
> code. Anyone with read access to the repository (which is anyone who can
> manage to correctly type the url) can get that code.
>
> Once we're 'happy' with it, we move it to a tag (which is just another
> directory, which, by convention is read only and for historical purposes)
> and we can make a release, even if it's only a zip that we just put up
> on sourceforge.
I understand now.
Thanks for the comprehensive explanation.
Regards,
Juergen
68. Re: Source changes
CChris wrote:
>
> > You could install coLinux + your favourite distribution and have a native
> > Linux
> > OS running side by side with Windows which would enable you to both >
> > Thanks, and Matt as well. I may try the coLinux approach first.
> If you hardly see me next week, suspect a computer messup, though I'll be able
> to access the list from office (where I am right now).
Either or I think. You won't mess up your computer with VMWare, and it's
'unlikely' with CoLinux (the worst is trying to make a folder in a cofs mount, a
native windows folder accessible from windows, that will spontaneously reboot
your computer, not good, use sftp, or make folders in Windows, not Linux).
The VMWare route is much easier to get set up and you end up with a nice GUI
straight away. The advantage of CoLinux is that it is not virtualised and
therefore faster (except for networking which they haven't found a faster way to
do yet). You have a better chance of working with real devices, as long as
Windows hasn't grabbed them already.
Another option to add to the mix is Bochs, http://bochs.sourceforge.net/ That is
definitely an emulator but good if you only want a command line development
environment.
BTW, I recommend Debian www.debian.org
(Simply because I've found its package management to be much more reliable, and
there's a prebuilt minimal Debian filesystem available for CoLinux)
(But I'm risking a major off topic thread, so I'll stop now :)
Gary
69. Re: Source changes
Gary Shingles wrote:
> Either or, I think. You won't mess up your computer with VMWare, and it's
> 'unlikely'
> with CoLinux (the worst is trying to make a folder in a cofs mount, a native
> windows folder accessible from windows. That will spontaneously reboot your
> computer, not good, use sftp, or make folders in Windows, not Linux).
Um, that is: "a native Windows folder accessible from within Linux".
Plus the extra comma.
Gary
70. Re: Source changes
Gary Shingles wrote:
>
> Either or I think. You won't mess up your computer with VMWare, and it's
> 'unlikely'
> with CoLinux (the worst is trying to make a folder in a cofs mount, a native
> windows folder accessible from windows, that will spontaneously reboot your
> computer, not good, use sftp, or make folders in Windows, not Linux).
>
> The VMWare route is much easier to get set up and you end up with a nice GUI
> straight away. The advantage of CoLinux is that it is not virtualised and
> therefore
> faster (except for networking which they haven't found a faster way to do
> yet).
> You have a better chance of working with real devices, as long as Windows
> hasn't
> grabbed them already.
The theory is that coLinux is faster, but I've had better luck with vmware.
Plus, you don't have to install anything extra to get a good GUI with vmware.
Getting x working with coLinux is a bit of a hassle. I used a the cygwin
x client, and it was also really slow. VNC or something else may work a lot
better. I've had a lot of success with NX Machine for doing remote linux
sessions, but I never tried it with coLinux.
YMMV
Matt
71. Re: Source changes
Matt Lewis wrote:
>
> Gary Shingles wrote:
> >
> > Either or I think. You won't mess up your computer with VMWare, and it's
> > 'unlikely'
> > with CoLinux (the worst is trying to make a folder in a cofs mount, a native
> > windows folder accessible from windows, that will spontaneously reboot your
> > computer, not good, use sftp, or make folders in Windows, not Linux).
> >
> > The VMWare route is much easier to get set up and you end up with a nice GUI
> > straight away. The advantage of CoLinux is that it is not virtualised and
> > therefore
> > faster (except for networking which they haven't found a faster way to do
> > yet).
> > You have a better chance of working with real devices, as long as Windows
> > hasn't
> > grabbed them already.
>
> The theory is that coLinux is faster, but I've had better luck with vmware.
> Plus, you don't have to install anything extra to get a good GUI with vmware.
> Getting x working with coLinux is a bit of a hassle. I used a the cygwin
> x client, and it was also really slow. VNC or something else may work a lot
> better. I've had a lot of success with NX Machine for doing remote linux
> sessions, but I never tried it with coLinux.
anyone tried this one? it's new on the scene, but looks pretty good.
http://www.virtualbox.org
72. Re: Source changes
Jules wrote:>
> anyone tried this one? it's new on the scene, but looks pretty good.
>
> <a href="http://www.virtualbox.org">http://www.virtualbox.org</a>
That looks interesting... thanks for the link!
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
74. Re: Source changes
Gary Shingles wrote:
>
> Matt Lewis wrote:
> >
> > The theory is that coLinux is faster, but I've had better luck with vmware.
> > Plus, you don't have to install anything extra to get a good GUI with
> > vmware.
> > Getting x working with coLinux is a bit of a hassle. I used a the cygwin
> > x client, and it was also really slow. VNC or something else may work a lot
> > better.
>
> Yep, I wouldn't bother with X on coLinux and then only with the vnc server at
> a minimal resolution.
>
> >I've had a lot of success with NX Machine for doing remote linux
> > sessions, but I never tried it with coLinux.
>
> I'd never heard of it. It looks interesting, a bit like Remote Desktop? It
> also looks like it costs
> real money I see there is a FreeNX movement,
> so I'll look that up.
>
> I just use coLinux for adding another server to a windows server or 2000/XP
> machine
> where you can run it (or two) as a service to do very basic stuff like
> mail/smb/mysql
> etc. and save a few hundred $$$ (and space on a rack) on another box. I
> very rarely use a GUI on Linux now; Windows does it so much better ;)
> Although I did
> set someone up at work once with an old iMac running powerpc Linux/Ubuntu/Open
> Office
> etc and that actually worked out quite well. What Gnome lacks in
> userfriendliness it
> more than makes up for in games and screensavers
>
> > YMMV
>
> As always
>
> If someone had VMWare they could set up a minimal development environment for
> Linux Euphoria with SVN all set up and then export the appliance couldn't
> they?
>
> Gary
I can't comment on vmware but you should give virtualbox a try. I only
discovered it yesterday and thought I'd try installing XP on my Ubuntu laptop.
Wow! this is very slick and amazingly easy to set up. One-click install, a
couple of minutes to set up the virtual machine (I allocated half of my 512Mb of
RAM) using the wizards, pop in the CD, and 40 minutes later I had a fully
functioning XP system running. Very impressive.
http://www.virtualbox.org
75. Re: Source changes
Jules wrote:
>
> I can't comment on vmware but you should give virtualbox a try. I only
> discovered
> it yesterday and thought I'd try installing XP on my Ubuntu laptop.
>
> Wow! this is very slick and amazingly easy to set up. One-click install, a
> couple
> of minutes to set up the virtual machine (I allocated half of my 512Mb of RAM)
> using the wizards, pop in the CD, and 40 minutes later I had a fully
> functioning
> XP system running. Very impressive.
>
> <a href="http://www.virtualbox.org">http://www.virtualbox.org</a>
Already on my hard drive I saw your other post and read up on it straight
away. I haven't tried anything yet though.
I predict that if you want to keep an XP setup handy you'll be looking at
putting another 512Mb RAM in your laptop :) I can't stand XP on only 256Mb, even
on a 3.0GHz machine.
Gary
76. Re: Source changes
Gary Shingles wrote:
>
> Jules wrote:
> >
> > I can't comment on vmware but you should give virtualbox a try. I only
> > discovered
> > it yesterday and thought I'd try installing XP on my Ubuntu laptop.
> >
> > Wow! this is very slick and amazingly easy to set up. One-click install, a
> > couple
> > of minutes to set up the virtual machine (I allocated half of my 512Mb of
> > RAM)
> > using the wizards, pop in the CD, and 40 minutes later I had a fully
> > functioning
> > XP system running. Very impressive.
> >
> > <a href="http://www.virtualbox.org">http://www.virtualbox.org</a>
>
> Already on my hard drive I saw your other post and
> read up on it straight away. I haven't tried anything yet though.
>
> I predict that if you want to keep an XP setup handy you'll be looking at
> putting
> another 512Mb RAM in your laptop :) I can't stand XP on only 256Mb, even on
> a 3.0GHz machine.
>
> Gary
You're right. It's a little jerky with 256Mb, but quite usable. I gig would be
fine I think. (512Mb each for the host and guest OS).
77. Re: Source changes
Gary Shingles wrote:
>
> >I've had a lot of success with NX Machine for doing remote linux
> > sessions, but I never tried it with coLinux.
>
> I'd never heard of it. It looks interesting, a bit like Remote Desktop? It
> also looks like it costs
> real money I see there is a FreeNX movement,
> so I'll look that up.
There's a free version:
http://www.nomachine.com/products.php
>
> If someone had VMWare they could set up a minimal development environment for
> Linux Euphoria with SVN all set up and then export the appliance couldn't
> they?
I suppose they could. That sounds like a worthy project.
Matt
78. Re: Source changes
Jules wrote:
>
> > > using the wizards, pop in the CD, and 40 minutes later I had a fully
> > > functioning
> > > XP system running. Very impressive.
> > >
> > > <a href="http://www.virtualbox.org">http://www.virtualbox.org</a>
> >
> > Already on my hard drive I saw your other post and
> > read up on it straight away. I haven't tried anything yet though.
> >
> > I predict that if you want to keep an XP setup handy you'll be looking at
> > putting
> > another 512Mb RAM in your laptop :) I can't stand XP on only 256Mb, even on
> > a 3.0GHz machine.
> >
> > Gary
>
> You're right. It's a little jerky with 256Mb, but quite usable. I gig would
> be fine I think. (512Mb each for the host and guest OS).
A colleague recommended <a
href="http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx">MS
VirtualPC</a>, which I tried and am very impressed with. I couldn't install
MINIX3 on VirtualBox (it had disk errors) but Virtual PC (2007) handled it
without a problem. It's free now too.
Gary
