1. RE: Bliss update
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C239BF.86A8C760
charset=iso-8859-1
You little ripper, mate! (ooops! Lapsed into Aussie)
Translation: A excellent job; well done Mr Bochert.
I'm tempted to start using it for real work now. Is it too late to suggest
another performance improvement?
I'd like to see a variation of the find() and match() functions.
findfrom(a,b,c)
and
matchfrom(a,b,c)
These would look for/match 'a' inside 'b', starting from the c'th
position. If c < 1 or > length(b) zero would be returned.
This would speed up many searching algorithms that need to look for multiple
instances of 'a' in 'b'.
------------
Derek.
> -----Original Message-----
> From: kbochert at ix.netcom.com [mailto:kbochert at ix.netcom.com]
> Sent: Friday, 2 August 2002 10:39
> To: EUforum
> Subject: Bliss update
>
>
>
> BLISS UPDATE
>
> I have just released the latest version of Bliss to the
> archives. It has (hopefully) reached maturity -- the only
> planned addition is making runtime errors into exceptions.
>
> It has been renamed 'Bach' because 'Bliss' was already taken.
> I liked Bliss. I was about to decide that a second Bliss was
> acceptable when I checked to see if any other language name
> was multiply used. Sure enough, I found one -- Bliss is used twice!
>
> Bach refers not to the composer, but to the Welsh word for little, or
> 'little one'. The 'ch' is pronounced as in the Scottish 'loch'.
>
> Changes:
>
> 1) Mersenne random # generator.
> drand() returns 0 <= N <= 1.0
> irand(l, h) returns l <= N <= h
> I thought it produced a more random sequence, but who knows?
> It is nearly twice as fast. EU:1440 MER_FLT:3200 MER_INT:2430
>
> 2) insert(seq, object, index) inserts an object into a list
> <for maintaining sorted lists>
>
> 3) exchange (seq, index1, index2) exchange items in a sequence
> This was added to speed sorts, and extraction from a sequence.
> The database bechmark goes from EU:600 to Bach:800
>
> 4) Instance initialization with new(). If a class has a method
> called new(), it may be called when creating an instance:
> Point p(2,3)
>
> 5) Overriding. A class may have members which are named the
> same as a member of a parent.
>
> 6) Parent access. The '..' operator may be used to access a
> member of a parent.
>
> 7) Member constants are allowed.
>
> 8) Bach no longer searches the subdirectories of the home
> 'include' directory. (Subdirectories of EUDIR\include are
> still searched.
>
> 9) The sprintf() function now understands '%c' for printing
> characters.
>
> 10) The '??' operator acts just like '?' except it pauses after
> output.
>
> 11) '$' and '_' are alphabetic characters.
>
> 12) A formal parameter whose name begins with '$' will not draw
> a warning message if it is not referenced.
>
>
> Karl Bochert
>
>
>
>
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C239BF.86A8C760
Content-Type: application/ms-tnef
2. RE: Bliss update
>I'd like to see a variation of the find() and match() functions.
>
> findfrom(a,b,c)
>and
> matchfrom(a,b,c)
>
> These would look for/match 'a' inside 'b', starting from the c'th
>position. If c < 1 or > length(b) zero would be returned.
>
>This would speed up many searching algorithms that need to look for
>multiple
>instances of 'a' in 'b'.
What's wrong with find(a,b[c..length(b)]) ?
I don't think you'd get much speed improvement.
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_ <-------------------/
\__| Mr Trick
3. RE: Bliss update
-------Phoenix-Boundary-07081998-
Hi Derek Parnell, you wrote on 8/1/02 4:54:58 PM:
>I'm tempted to start using it for real work now.
> Is it too late to suggest another performance improvement=3F
>
Alas, too late for Ver 1.1. I am sensitive to the issue though.
Sequences are the soul of Euphoria, and I think that anything
that can improve them is worth serious consideration.
An interesting possibility is to overload 'find' on the number
of parameters and have both:
find (item, seq)
and:
find (item, seq, start)
Sound good=3F or bad=3F
Below is my current wish-list for Ver 2.0
The wish list as of now: (subject to rapid change)
1) Overload methods on # of parameters
2) Allow ++-- at end of line
3) User-specified fct to handle uncaught exceptions
4) Run-time errors generate exceptions
5) Reseller license
6) Simpler DLL interface (may not be possible)
7) Interfaces to IUP, SQLite, and TCP4u
8) Buit-in extract(seq, index)
9) Build in PCRE
-------Phoenix-Boundary-07081998---
4. RE: Bliss update
On 2 Aug 2002, at 13:12, kbochert at ix.netcom.com wrote:
>
> Hi Derek Parnell, you wrote on 8/1/02 4:54:58 PM:
>
>
> >I'm tempted to start using it for real work now.
>
> > Is it too late to suggest another performance improvement?
> >
>
> Alas, too late for Ver 1.1. I am sensitive to the issue though.
> Sequences are the soul of Euphoria, and I think that anything
> that can improve them is worth serious consideration.
>
> An interesting possibility is to overload 'find' on the number
> of parameters and have both:
> find (item, seq)
> and:
> find (item, seq, start)
>
> Sound good? or bad?
Sounds good, in a way. I think this may lead to a little confusion. I would use
find(item,seq) and find_from(item,seq). I considered doing something like
that in strtok-v2, but i decided to nest some parameters, and change the
name of case-insensitive functions.
> Below is my current wish-list for Ver 2.0
>
> The wish list as of now: (subject to rapid change)
>
> 1) Overload methods on # of parameters
Hmmmm
> 2) Allow ++-- at end of line
>
> 3) User-specified fct to handle uncaught exceptions
>
> 4) Run-time errors generate exceptions
For more "professional" shutdowns. 
> 5) Reseller license
How about lower price for source?
> 6) Simpler DLL interface (may not be possible)
>
> 7) Interfaces to IUP, SQLite, and TCP4u
As much as i use tcp4u, i suggest you do NOT interface to it, for 5 reasons:
1) needs tcp4u.dll
2) the tcp4u.ew is not fixed
3) tcp4u is blocking
4) there are more options in using the api calls, and tcp4u uses only a few of
them.
5) I'd like to see all the internet functions in winsock, and whatever dos uses
(Trumpet?), and linux, made available in the core Eu, transparently to the
programmer, so a call in Euphoria on *nix or dos or win95 gives the same
results. Ever look at Rebol?
> 8) Buit-in extract(seq, index)
That's a string function, yes? Nested "string" function? I don't know if it is
worth mentioning, but i was going to make *one* .ew for string functions,
since i use them, and haveto watch what i include for nearly every program. If
you include string functions, may i suggest we discuss strtok also?, it's just
as valid a lib. I suspect you will have more applications where several layers
of processing are needed before you get to the point of using mid_str().
> 9) Build in PCRE
Who? What?
Kat
5. RE: Bliss update
-------Phoenix-Boundary-07081998-
Hi Kat, you wrote on 8/2/02 5:11:41 PM:
>> An interesting possibility is to overload 'find' on the number
>> of parameters and have both:
>> find (item, seq)
>> and:
>> find (item, seq, start)
>>
>> Sound good=3F or bad=3F
>
>Sounds good, in a way. I think this may lead to a little confusion. I
>would use find(item,seq) and find_from(item,seq). I considered doing
>something like that in strtok-v2, but i decided to nest some
> parameters, and change the name of case-insensitive functions.
>
I like the overloaded function foe several reasons.
1) The overloading is actually more like an optional parameter
The 'real' function is find(i,s,start), but the start may be
omitted for compatibility with Euphoria.
2) It is easier for me to remember a single function name.
3) It is easier to implement (less code, smaller symbol table)
>> 1) Overload methods on # of parameters
>
>Hmmmm
>
The primary use is to allow multiple instance initializers
('new' methods).
>
> 5) Reseller license
>
>How about lower price for source=3F
>
I havn't really considered offering source code. If I were to offer
source code like Rob, the purchaser would have to purchase 2 sets
of code -- gets pretty expensive. I was thinking that if a user
wished to offer a commercial application using Bach, I could
provide a way for the user to 'piggy-back' on my licensing
arrangement.
> 7) Interfaces to IUP, SQLite, and TCP4u
>
>As much as i use tcp4u, i suggest you do NOT interface to it, for 5
>reasons:
>1) needs tcp4u.dll
>2) the tcp4u.ew is not fixed
>3) tcp4u is blocking
>4) there are more options in using the api calls, and tcp4u uses only a
> few of them.
>5) I'd like to see all the internet functions in winsock, and whatever dos
>uses (Trumpet=3F), and linux, made available in the core Eu, transparently
to
> the programmer, so a call in Euphoria on *nix or dos or win95 gives the
> same results.
Yes, but I probably will not offer a Dos version, and *nix is probably
far on the future. I know nothing about the world of TCP, so I'm open
to suggestions
> Ever look at Rebol=3F
Only very briefly. It may very well be that Internet things are
handled so well by languages like Rebol that there is little point
in putting too much support into Bach. I shall learn, eventually.
>>
>> 8) Buit-in extract(seq, index)
>>
>That's a string function, yes=3F Nested "string" function=3F I don't know
>if it is worth mentioning, but i was going to make *one* .ew for
>string functions, since i use them, and have to watch what i include
>for nearly every program. If you include string functions, may i
>suggest we discuss strtok also=3F, it's just as valid a lib. I suspect
>you will have more applications where several layers of processing
>are needed before you get to the point of using mid_str().
>
The issue is what sequence primitives should be included. Rob has
chosen a minimalist set, which I am inclined to enlarge. I would
envision that a library for string and sequence manipulation
still would be needed -- What primitives would most help in the
creation of that library=3F
>> 9) Build in PCRE
>>
>Who=3F What=3F
Perl Compatible Regular Expressions is a comprehensive and
powerful way to deal with the myriad ways we want to process
strings.
Some time ago I submitted a Euphoria library to interface with
the PCRE dll. I recently ran a benchmark comparing the speed
of PCRE versus a Euphoria string library (yours=3F). The result
was pretty even, though I would expect that PCRE would get
better as the test got larger. I hope that embedding
PCRE into Bach might produce a clear advantage.
Note that PCRE only deals with strings -- more complex
sequences still require find() etc.
Karl Bochert
-------Phoenix-Boundary-07081998---
6. RE: Bliss update
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C23C11.AD19B950
charset=iso-8859-1
> -----Original Message-----
> From: kbochert at ix.netcom.com [mailto:kbochert at ix.netcom.com]
> Subject: RE: Bliss update
>
>
>
> Hi Derek Parnell, you wrote on 8/1/02 4:54:58 PM:
>
>
> >I'm tempted to start using it for real work now.
>
> > Is it too late to suggest another performance improvement?
> >
>
> Alas, too late for Ver 1.1. I am sensitive to the issue though.
> Sequences are the soul of Euphoria, and I think that anything
> that can improve them is worth serious consideration.
>
> An interesting possibility is to overload 'find' on the number
> of parameters and have both:
> find (item, seq)
> and:
> find (item, seq, start)
>
> Sound good? or bad?
>
Sounds good. I regard find(item, seq) as actually being find(item, seq, 1).
> Below is my current wish-list for Ver 2.0
>
> The wish list as of now: (subject to rapid change)
>
> 1) Overload methods on # of parameters
Excellent. I'll doing this a lot in the new win32lib and other 'real work'
for Eu. It would be nice to have it natively supported.
> 2) Allow ++-- at end of line
What would that do?
> 3) User-specified fct to handle uncaught exceptions
Hopeful this would be a with/without option.
> 4) Run-time errors generate exceptions
>
> 5) Reseller license
>
> 6) Simpler DLL interface (may not be possible)
The only hard part currently is mapping C structures to RAM offsets, and
remembering to store and fetch the correct datatype. David Cuny's
allot/store/fetch routines in tk_mem.e (win32lib.ew include) emulate most
things now but it would be nice to be natively supported.
> 7) Interfaces to IUP, SQLite, and TCP4u
Hopefully this is a very low priority.
> 8) Buit-in extract(seq, index)
Do you have plans for other list handling operations?
--------------
Derek.
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C23C11.AD19B950
Content-Type: application/ms-tnef
7. RE: Bliss update
- Posted by kbochert at copper.net
Aug 04, 2002
-------Phoenix-Boundary-07081998-
Hi Derek Parnell, you wrote on 8/4/02 3:49:27 PM:
> An interesting possibility is to overload 'find' on the number
> of parameters and have both:
> find (item, seq)
> and:
> find (item, seq, start)
>
> Sound good=3F or bad=3F
>
>
>Sounds good. I regard find(item, seq) as actually being find(item, seq, 1).
>
>
> Below is my current wish-list for Ver 2.0
>
> The wish list as of now: (subject to rapid change)
>
> 1) Overload methods on # of parameters
>
>Excellent. I'll doing this a lot in the new win32lib and other 'real work'
>for Eu. It would be nice to have it natively supported.
>
> 2) Allow ++-- at end of line
>
>What would that do=3F
++-- ends a block comment. Currently it must be at the start of a line.
Probably good enuf.
>
> 3) User-specified fct to handle uncaught exceptions
>
>Hopeful this would be a with/without option.
I would envision a built-in variable $CRASH$
If you wished to catch fatal errors you would assign
a function to it.
$CRASH$ =3D routine_id ("CleanUp")
That way you could change (or eliminate) the cleanup
code as the program progresses.
>
> 4) Run-time errors generate exceptions
>
> 5) Reseller license
>
> 6) Simpler DLL interface (may not be possible)
>
>The only hard part currently is mapping C structures to RAM offsets, and
>remembering to store and fetch the correct datatype. David Cuny's
>allot/store/fetch routines in tk_mem.e (win32lib.ew include) emulate most
>things now but it would be nice to be natively supported.
>
I'll take a look at tk_mem.e Dll interfaces follow such a consistent
pattern that its hard to believe they can't be automated better. Don't
know how though.
> 7) Interfaces to IUP, SQLite, and TCP4u
>
>Hopefully this is a very low priority.
>
I am currently working on the interface to IUP (a library - no
specific interpreter support). I really like IUP as a small and
simple GUI. So far buttons, toggles, checkboxes, radios, text,
lists, menus, and color selections work, with remarkably little
code. I may attempt their 2D drawing library as well.
-- 'Canvas Draw' <http://www.tecgraf.puc-rio.br/cd/> --
> 8) Built-in extract(seq, index)
>
>Do you have plans for other list handling operations=3F
>
No, but I'm open to suggestion. They are quite a bit of
work though, and I'm not even sure about extract().
Regards
Karl Bochert
-------Phoenix-Boundary-07081998---
8. RE: Bliss update
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C23C3F.0EBC1A90
charset=iso-8859-1
> -----Original Message-----
> From: kbochert at copper.net [mailto:kbochert at copper.net]
> Subject: RE: Bliss update
> > 2) Allow ++-- at end of line
> >
> >What would that do?
>
> ++-- ends a block comment. Currently it must be at the start
> of a line.
> Probably good enuf.
Yeah, I wouldn't worry too much. Helps it stand out to, I suppose.
>
> > 8) Built-in extract(seq, index)
> >
> >Do you have plans for other list handling operations?
> >
>
> No, but I'm open to suggestion. They are quite a bit of
> work though, and I'm not even sure about extract().
I was just thinking that currently, the operations to insert or delete an
item from a sequence requires us to create two temporary sequences and
concatenate them. I was hoping that these common operations might be faster
done inside the interpreter core.
insert_item(seq, index, object) ==> seq[1..index-1] & object &
seq[index..length(seq)]
delete_item(seq, index) ==> seq[1..index-1] & seq[index+1..length(seq)]
These are common operations too...
-- drop the first item (opposite of prepend)
tail(seq) ==> seq[2 .. length(seq)]
-- drop the last item (opposite of append)
head(seq) ==> seq(1 .. length(seq)-1]
Obviously, they can all be done with standard Eu, however at what cost? As
they are commonly employeed, it might be worth investigating if there are
any benefits in doing these in core Eu.
-----------
cheers,
Derek.
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C23C3F.0EBC1A90
Content-Type: application/ms-tnef
9. RE: Bliss update
On 4 Aug 2002, at 19:38, kbochert at copper.net wrote:
> I am currently working on the interface to IUP (a library - no
> specific interpreter support). I really like IUP as a small and
> simple GUI. So far buttons, toggles, checkboxes, radios, text,
> lists, menus, and color selections work, with remarkably little
> code. I may attempt their 2D drawing library as well.
> -- 'Canvas Draw' <http://www.tecgraf.puc-rio.br/cd/> --
Your browser does not support JavaScript or it is disabled.
This page uses frames, but your browser doesn't support them.
Since when does IE5 not support frames??? Those folks at Lua are getting really
un-user-friendly!
Kat
