1. Is anyone still interested in the Euphoria Standard Library project?
Just to know whether developing tools for it would be beneficial...
I recently coded a locate.e module which will largely extend find and match
functionality. Here's the most general form:
object x
x=generic_locate(what,source,options)
options is a {name,value} ppair list. Allowable names are:
ALL - return a sequence of matches,not just one
ANY - interpret what as a sequence of items to be looked for
COUNT - Rank or number of items to return, 0 to men "all matches". Negative
values cause reverse search.
DIR - specify search direction when not included in the count option
EXTRACT - returns items rather than locations
FILTER - use a specific routine instead of standard comparison
MODE - count, find or match
NESTED - search sequence elements too
RMODE - return raw result, or a value()-like result
SLICE - restrict the part of source to be inspected
Testing all combinations will take some time, so, even if I release this as
a standalone library outside of the ESL, it won't be released very soon.
Currently, the library uses local variables through recursive calls and is not
reentrant. However, thre's no mechanism to enforce/warn against this now.
Question: is the multitasking API providing a standard way to report that a
resource is not available? (calll this a semaphore, fort short)?
CChris
2. Re: Is anyone still interested in the Euphoria Standard Library project?
CChris wrote:
> Question: is the multitasking API providing a standard way to report that a
> resource is not available? (calll this a semaphore, fort short)?
With Euphoria's cooperative multitasking, you can easily use a global
variable to control access to shared resources, and it is less common
that you actually need to worry about this sort of thing.
With pre-emptive threading on the other hand, it's necessary to have
special operating system calls to lock or unlock things, or set up
semaphores, since a thread could lose control at any moment,
even in the middle of executing a simple statement.
Note: with pre-emptive threads, you can't even safely increment a
global variable that is shared by multiple threads. e.g.
Suppose thread 1 wants to do:
x = x + 1
This might be executed at the machine level by:
1. load x from memory into a register
2. add 1 to the register
3. save the register value back into memory for x
but the operating system could switch to a new thread 2
after step 1 or 2, but before step 3. Suppose thread 2
increments x and then control returns and we perform step 3.
Step 3 will overwrite the value stored by thread 2,
as if it never happened, and the value of x will increase
by 1 not 2. To avoid this, it's necessary to lock/unlock x
each time you want to modify it. Of course programmers
frequently forget this and their program runs fine for
months before dying mysteriously.
Fortunately Euphoria programmers are spared this level
of concern for locking.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Is anyone still interested in the Euphoria Standard Library project?
CChris wrote:
>
> Just to know whether developing tools for it would be beneficial...
> I recently coded a locate.e module which will largely extend find and match
> functionality. Here's the most general form:
<snip code>
I've been wondering if people have lost interest in the project as well. I
haven't received any new messages on the ESL mailing list and my suggestions that
I have submitted to the list several times have not been included on the web
page.
I think I'll just implement some stuff on my own and submit it to the archives.
If the project is revived and if the group agrees with what I've done then
whatever I do can be integrated into ESL at that time.
j.
4. Re: Is anyone still interested in the Euphoria Standard Library project?
Jason Gade wrote:
>
>
> I've been wondering if people have lost interest in the project as well. I
> haven't
> received any new messages on the ESL mailing list and my suggestions that I
> have
> submitted to the list several times have not been included on the web page.
...
I just realized that the updated pages were never uploaded....
Sorry, I'll upload the pages as soon as possible.
5. Re: Is anyone still interested in the Euphoria Standard Library project?
Robert Craig wrote:
>
> CChris wrote:
> > Question: is the multitasking API providing a standard way to report that a
> > resource is not available? (calll this a semaphore, fort short)?
>
> With Euphoria's cooperative multitasking, you can easily use a global
> variable to control access to shared resources, and it is less common
> that you actually need to worry about this sort of thing.
> With pre-emptive threading on the other hand, it's necessary to have
> special operating system calls to lock or unlock things, or set up
> semaphores, since a thread could lose control at any moment,
> even in the middle of executing a simple statement.
>
> Note: with pre-emptive threads, you can't even safely increment a
> global variable that is shared by multiple threads. e.g.
> Suppose thread 1 wants to do:
>
> x = x + 1
>
> This might be executed at the machine level by:
>
> 1. load x from memory into a register
> 2. add 1 to the register
> 3. save the register value back into memory for x
>
> but the operating system could switch to a new thread 2
> after step 1 or 2, but before step 3. Suppose thread 2
> increments x and then control returns and we perform step 3.
> Step 3 will overwrite the value stored by thread 2,
> as if it never happened, and the value of x will increase
> by 1 not 2. To avoid this, it's necessary to lock/unlock x
> each time you want to modify it. Of course programmers
> frequently forget this and their program runs fine for
> months before dying mysteriously.
>
> Fortunately Euphoria programmers are spared this level
> of concern for locking.
>
Cooperative tasking is just execution of a single thread switching from one
routine (task) to the next with a call to task_yield(), in a scheduled manner.
Cooperative tasking does not allow multiple sections of code (threads) to
execute simultaneously on multi-core or multiple processor machines.
On single core, single processor machines, cooperative tasking is fine.
Pre-emptive O/S thread programming would be a burden that offers very few
benefits over an emulated solution, since in the end it would just be context
switching.
But Intel is working on developing quad core technology, and increasing
production on dual core CPUs, AMD is probably doing the same. So with multi-core
or multiple processor machines, cooperative task switching is not effectively
utilizing more than one core or processor at a given time. So with that said, it
is more likely that other thread safe/aware interpreted languages could start
catching up to Euphoria in terms of speed (despite mutex locking overhead) if
programmers were to start adopting multiple thread programming in their
applications and/or libraries with their multi-core or multiple processor
machines and operating systems that have thread APIs that support these CPUs.
Multi-core 64 bit computers are on the rise, and eventually they will become the
majority. I dont have one yet, but my next is going to be.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
6. Re: Is anyone still interested in the Euphoria Standard Library project?
This makes my rfind and generic.e find_all redundant. I especially like the
FILTER option although the paticular identifer "FILTER" is a bit cryptic.
Why do you have a SLICE option when you do not even need to add a
line of code to send a slice of what instead of what?
CChris wrote:
>
> Just to know whether developing tools for it would be beneficial...
> I recently coded a locate.e module which will largely extend find and match
> functionality. Here's the most general form:
>
> }}}
<eucode>
> object x
> x=generic_locate(what,source,options)
> </eucode>
{{{
>
> options is a {name,value} ppair list. Allowable names are:
>
> ALL - return a sequence of matches,not just one
> ANY - interpret what as a sequence of items to be looked for
> COUNT - Rank or number of items to return, 0 to mean "all matches". Negative
> values
> cause reverse search.
> DIR - specify search direction when not included in the count option
> EXTRACT - returns items rather than locations
> FILTER - use a specific routine instead of standard comparison
> MODE - count, find or match
> NESTED - search sequence elements too
> RMODE - return raw result, or a value()-like result
> SLICE - restrict the part of source to be inspected
>
> Testing all combinations will take some time, so, even if I release this as
> a standalone library outside of the ESL, it won't be released very soon.
>
> Currently, the library uses local variables through recursive calls and is not
>
> reentrant. However, thre's no mechanism to enforce/warn against this now.
>
> Question: is the multitasking API providing a standard way to report that a
> resource is not available? (calll this a semaphore, fort short)?
>
> CChris
>
7. Re: Is anyone still interested in the Euphoria Standard Library project?
Hello there,
I still think it's a good idea. I'd contribute too.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
