1. Standard library progress

Well, I've made some progress. I've put online in a temporary location Euphoria
documentation with the new functions I've added. I did this temporarily for
feedback, the documentation there will be removed after a few days. For those of
you who wish to get a good look at what I've done, please visit the source forge
project page and look at the SVN repo or do a checkout for yourself.

The location of the docs are: http://jeremy.cowgar.com/euphoria/library.htm

I've added over 110 tests that anyone can run in the new Euphoria. cd tests and
exu (or exw) all.ex ... the unit tests will run right there. They are testing
some existing functions and all of the new functions added. Before I consider a
function completed, it is developed, tested and documented. As bugs are found,
tests will be created to expose those bugs, then the bugs fixed (and we know they
are fixed because the previously failing tests now pass).

The functions I've added thus far can be seen in the release notes:
http://jeremy.cowgar.com/euphoria/relnotes.htm

Again, this is a temporary document upload just so I can get feedback. They will
be removed in a few days. Do not link to these documents.

Thanks for any feedback, suggestions, bug fixes, unit tests, document
corrections, etc...

There are many more functions coming. Documentation is the part that takes the
most time.

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » topic index » view message » categorize

2. Re: Standard library progress

Hey, Jeremy, here's some requests... :)

> I've added over 110 tests that anyone can run in the new Euphoria.

I'd like to see a pause at the end of all.ex so my screen doesn't flash
away if I'm using it in Windows.

Also, is findany_from() going to be able to use wildcards?

x = findany_from( "{*}","This {is} text {and} so {is this}." )
-- x = 6

8)

new topic     » goto parent     » topic index » view message » categorize

3. Re: Standard library progress

c.k.lester wrote:
> 
> Hey, Jeremy, here's some requests... :)
> 
> > I've added over 110 tests that anyone can run in the new Euphoria.
> 
> I'd like to see a pause at the end of all.ex so my screen doesn't flash
> away if I'm using it in Windows.

Hm, I always use exwc when in windows, so it does not start a 2nd console. The
plan is to eventually allow builds to run all.ex and check the exit code to
determine if all the tests passed or not. Therefore, a pause at the end would
cause problems there. I could make it a switch if necessary.

> 
> Also, is findany_from() going to be able to use wildcards?
> 
> x = findany_from( "{*}","This {is} text {and} so {is this}." )
> -- x = 6
> 
> 8)

No, findany does not work like that. findany and findany_from works on atoms.
For instance, findany_from(str, "aeiou") it will find the first a, first e, first
i, etc...  Wouldn't wildcard_match do that for you?

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

4. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> Wouldn't wildcard_match do that for you?

Hm, that only returns true/false, sorry about that.

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

5. Re: Standard library progress

Jeremy Cowgar wrote:
> c.k.lester wrote:
> > I'd like to see a pause at the end of all.ex so my screen doesn't flash
> > away if I'm using it in Windows.
> determine if all the tests passed or not. Therefore, a pause at the end would
> cause problems there. I could make it a switch if necessary.

Yeah, that sounds reasonable.

> > Also, is findany_from() going to be able to use wildcards?
> > 
> > x = findany_from( "{*}","This {is} text {and} so {is this}." )
> > -- x = 6
> 
> No, findany does not work like that.

Well, it should. :P

Okay, no... we need a separate set of functions.

find_wildcard( w, str )

which would basically return the position (start and end) of the first
matching string segment.

x = find_wildcard( "{*}", "Madlibs let's you {verb} a story!" )
-- x = { 19, 24 }

new topic     » goto parent     » topic index » view message » categorize

6. Re: Standard library progress

c.k.lester wrote:
> 
> Okay, no... we need a separate set of functions.

These might do it:

Aron's <a href="http://www.rapideuphoria.com/wildcard.zip">Advanced Wildcard
Library</a>
David Cuny's <a href="http://www.rapideuphoria.com/pattern.zip">Pattern Matching
for Text Strings</a>

new topic     » goto parent     » topic index » view message » categorize

7. Re: Standard library progress

c.k.lester wrote:
> 
> Okay, no... we need a separate set of functions.
> 
> find_wildcard( w, str )
> 
> which would basically return the position (start and end) of the first
> matching string segment.
> 
> x = find_wildcard( "{*}", "Madlibs let's you {verb} a story!" )
> -- x = { 19, 24 }

Yes, that seems reasonable. I don't want to sound pushy, but do you have that
function or an idea how it would work? It'd be great if you could create it, the
docs and a few tests to prove it works. You could then commit it smile If not, I'll
add it to my list of functions to find/create.

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

8. Re: Standard library progress

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> >
> > No, findany does not work like that.
> 
> Well, it should. :P
> 
> Okay, no... we need a separate set of functions.
> 
> find_wildcard( w, str )

I think that what this is really saying is that we could use built-in regular
expressions.

Matt

new topic     » goto parent     » topic index » view message » categorize

9. Re: Standard library progress

Matt Lewis wrote:
> 
> 
> I think that what this is really saying is that we could use built-in regular
> expressions.
> 

Yes, I agree. I've used regular expressions many, many times and I do not
remember once when I used *just* a wildcard.

Now, implementing regular expressions is not a trivial task as everyone knows.
However, it may be a trivial task to make a cross platform wrap around pcre or
something. The Archive has a windows only wrap by Karl Bochert. That could
probably be easily modified to work on Linux/FreeBSD as well.

What do you think? Would pcre.e be a valid part of the standard library? The
difference I see is that it would bring about an additional dependency, which
doesn't sound very attractive to me but regular expressions do sound attractive
to me. PCRE is licensed as such that it could be distributed with Euphoria, but
then again, it increases the download size and makes the build process a bit more
complicated. How much? I don't really know right now.

Suggestions? Thoughts?

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

10. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> Matt Lewis wrote:
> > 
> > 
> > I think that what this is really saying is that we could use built-in
> > regular
> > expressions.
> > 
> 
> Yes, I agree. I've used regular expressions many, many times and I do not
> remember
> once when I used *just* a wildcard.
> 
> Now, implementing regular expressions is not a trivial task as everyone knows.
> However, it may be a trivial task to make a cross platform wrap around pcre
> or something. The Archive has a windows only wrap by Karl Bochert. That could
> probably be easily modified to work on Linux/FreeBSD as well.
> 
> What do you think? Would pcre.e be a valid part of the standard library? The
> difference I see is that it would bring about an additional dependency, which
> doesn't sound very attractive to me but regular expressions do sound
> attractive
> to me. PCRE is licensed as such that it could be distributed with Euphoria,
> but then again, it increases the download size and makes the build process a
> bit more complicated. How much? I don't really know right now.

PCRE is exactly what I'm thinking.  Ideally, I think it would be statically
linked to the interpreter.  Of course, this will increase the size, but it
would be nice to have them as a native part of the language.

Matt

new topic     » goto parent     » topic index » view message » categorize

11. Re: Standard library progress

Matt Lewis wrote:
> 
> PCRE is exactly what I'm thinking.  Ideally, I think it would be statically
> linked to the interpreter.  Of course, this will increase the size, but it
> would be nice to have them as a native part of the language.
> 

Matt, 

Is this something you can do? I've not worked with linking new things to the
interpreter. I do agree that regular expressions is a pretty important part.


--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

12. Re: Standard library progress

Matt Lewis wrote:
> c.k.lester wrote:
> > find_wildcard( w, str )
> I think that what this is really saying is that we could use built-in regular
> expressions.

Yes, that's it! :)

new topic     » goto parent     » topic index » view message » categorize

13. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> Well, I've made some progress. I've put online in a temporary location
> Euphoria
> documentation with the new functions I've added. I did this temporarily for
> feedback, the documentation there will be removed after a few days. For those
> of you who wish to get a good look at what I've done, please visit the source
> forge project page and look at the SVN repo or do a checkout for yourself.
> 
> The location of the docs are: <a
> href="http://jeremy.cowgar.com/euphoria/library.htm">http://jeremy.cowgar.com/euphoria/library.htm</a>
> 
> I've added over 110 tests that anyone can run in the new Euphoria. cd tests
> and exu (or exw) all.ex ... the unit tests will run right there. They are
> testing
> some existing functions and all of the new functions added. Before I consider
> a function completed, it is developed, tested and documented. As bugs are
> found,
> tests will be created to expose those bugs, then the bugs fixed (and we know
> they are fixed because the previously failing tests now pass).
> 
> The functions I've added thus far can be seen in the release notes:
> <a
> href="http://jeremy.cowgar.com/euphoria/relnotes.htm">http://jeremy.cowgar.com/euphoria/relnotes.htm</a>
> 
> Again, this is a temporary document upload just so I can get feedback. They
> will be removed in a few days. Do not link to these documents.
> 
> Thanks for any feedback, suggestions, bug fixes, unit tests, document
> corrections,
> etc...
> 
> There are many more functions coming. Documentation is the part that takes the
> most time.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

You can borrow from work I had done for the now defunct ESL:
http://oedoc.free.fr/Fichiers/ESL/
locate.e may need some reworking, as it had been designed before find_from() and
match_from() were added to Eu.

CChris

new topic     » goto parent     » topic index » view message » categorize

14. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> Matt Lewis wrote:
> > 
> > 
> > I think that what this is really saying is that we could use built-in
> > regular
> > expressions.
> > 
> 
> Yes, I agree. I've used regular expressions many, many times and I do not
> remember
> once when I used *just* a wildcard.
> 
> Now, implementing regular expressions is not a trivial task as everyone knows.
> However, it may be a trivial task to make a cross platform wrap around pcre
> or something. The Archive has a windows only wrap by Karl Bochert. That could
> probably be easily modified to work on Linux/FreeBSD as well.
> 
> What do you think? Would pcre.e be a valid part of the standard library? The
> difference I see is that it would bring about an additional dependency, which
> doesn't sound very attractive to me but regular expressions do sound
> attractive
> to me. PCRE is licensed as such that it could be distributed with Euphoria,
> but then again, it increases the download size and makes the build process a
> bit more complicated. How much? I don't really know right now.
> 
> Suggestions? Thoughts?
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

<plug>
Add EuRegExp from the archive to the standard distro.
</plug>

CChris

new topic     » goto parent     » topic index » view message » categorize

15. Re: Standard library progress

CChris wrote:
> 
> <plug>
> Add EuRegExp from the archive to the standard distro.
> </plug>
> 

Chris,

I am concerned about a few things in doing that. Maybe you can answer these
concerns since you wrote it smile

1. How fast is it compared to PCRE?
2. How complete is it?
3. How complex is it to maintain?

#3 is pretty important, because as we add to the Euphoria library we are not
only making new functions available to everyone, but we are taking on a large
amount of code to maintain as well. So, when something needs updated now, it's up
to the Euphoria developers to do so, no the author of lib ABC, or whatever. Now,
hopefully user DEF will say hey, ABC has a bug, here's a test to exploit that bug
and here's the patch to fix that bug, but we will see.

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

16. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> CChris wrote:
> > 
> > <plug>
> > Add EuRegExp from the archive to the standard distro.
> > </plug>
> > 
> 
> Chris,
> 
> I am concerned about a few things in doing that. Maybe you can answer these
> concerns since you wrote it smile
> 
> 1. How fast is it compared to PCRE?

I haven't tried, but can do some benchmarks on large text files. I'd expect PCRE
to be a bit faster. The code hasn't been optimised much. Note that optimised code
is usually a problem regarding your point #3.

> 2. How complete is it?

Pretty much, and it has some distinctive features I'm not aware that PCRE has,
like filtering matches, apply Eu operators to perform replacements and such. Did
you check the docs?

> 3. How complex is it to maintain?
> 
> #3 is pretty important, because as we add to the Euphoria library we are not
> only making new functions available to everyone, but we are taking on a large
> amount of code to maintain as well. So, when something needs updated now, it's
> up to the Euphoria developers to do so, no the author of lib ABC, or whatever.
> Now, hopefully user DEF will say hey, ABC has a bug, here's a test to exploit
> that bug and here's the patch to fix that bug, but we will see.
> 

Since I wrote it, I could tell you the code is not too hard to maintain smile
However, it is probably not commented enough for release as part of the standard
lib, ie for others to maintain effortlessly. If you are interested, I can add
more. I had strived to make the documentation complete and clear, so hopefully
that part will be ok.

CChris

> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

new topic     » goto parent     » topic index » view message » categorize

17. Re: Standard library progress

Let's get the opinion of the mass and see what they think. I did look at the
docs and it looks pretty interesting. Can you do me a favor? Can you do a few
benchmarks and then give an example or two as to where it integrates w/Euphoria
much better and post a new thread recommending that it be added to the standard
lib? Others can then see the benchmarks and the benefits and we can start a
discussion.

It is pretty nice to have it as Euphoria code vs. requiring the interpreter to
link against PCRE, changing the build process, bumping up the binary size, etc...

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

18. Re: Standard library progress

Jeremy:

   How come you are telling users not to prefix their routines.

   It looks like thats what you did in your iup. wrapper.

   I think before you consider changing the basic core of Euphoria,

   that you consider starting a whole new seperate version, that way

   you could completely redesign the include files and core to meet

   your expectations without breaking exist code.

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

new topic     » goto parent     » topic index » view message » categorize

19. Re: Standard library progress

Bernie Ryan wrote:
>    How come you are telling users not to prefix their routines.
>    It looks like thats what you did in your iup. wrapper.
>    I think before you consider changing the basic core of Euphoria,
>    that you consider starting a whole new seperate version, that way
>    you could completely redesign the include files and core to meet
>    your expectations without breaking exist code.

Bernie,

I am not sure what you mean? I did not tell anyone anything about not prefixing
vs. prefixing. Only one other person contributed code thus far and it is prefixed
as map_???.

Now, I am in favor of not prefixing. About Iup, I wrapped Iup identical to the C
library Iup as it is written so that you can use the documentation for Iup with
the Euphoria version. For instance, IupGetAttribute is the name of the C
function, so that's what I made the Euphoria version named.

In addition, Iup is a 3rd party library, it's not part of core C. It seems that
most other people like what's happening thus far. Would you have all new
functions prefixed? Such as the new peek2? maybe it should be memory_peek2 in
case someone else has already defined a function called peek2? Therefore, when we
go to use peek functions we are not sure if we should use peek2 or mem_peek2 or
memory_peek2?
 
--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

20. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> Now, I am in favor of not prefixing.

I agree.  Starting with 3.2, namespaces will be much more powerful.  This 
will be the proper way to deconflict these clashes.  I think that at this 
point it will be possible to resolve any conflict without changing any
3rd party code.

Matt

new topic     » goto parent     » topic index » view message » categorize

21. Re: Standard library progress

Will do that, but after ironing out a couple issues with win32lib. I hope to
release v0.70.4a around May 15, and then will start the benchmarks.
If you look at the advanced examples in the docs, there are already some
instances of using Eu sequence operations in the filtering. I'll cobble out more
examples and post them in the meantime.

CChris

Jeremy Cowgar wrote:
> 
> Let's get the opinion of the mass and see what they think. I did look at the
> docs and it looks pretty interesting. Can you do me a favor? Can you do a few
> benchmarks and then give an example or two as to where it integrates
> w/Euphoria
> much better and post a new thread recommending that it be added to the
> standard
> lib? Others can then see the benchmarks and the benefits and we can start a
> discussion.
> 
> It is pretty nice to have it as Euphoria code vs. requiring the interpreter
> to link against PCRE, changing the build process, bumping up the binary size,
> etc...
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

new topic     » goto parent     » topic index » view message » categorize

22. Re: Standard library progress

CChris wrote:
> 
> Will do that, but after ironing out a couple issues with win32lib. 

Chris,

It's not dependent on win32lib is it? win32lib is just a higher priority is what
your saying? (which is fine, but just want to make sure it's not dependent).

Jeremy

new topic     » goto parent     » topic index » view message » categorize

23. Re: Standard library progress

Jeremy Cowgar wrote:
> 
> CChris wrote:
> > 
> > Will do that, but after ironing out a couple issues with win32lib. 
> 
> Chris,
> 
> It's not dependent on win32lib is it? win32lib is just a higher priority is
> what your saying? (which is fine, but just want to make sure it's not
> dependent).
> 
> Jeremy

Exactly. RL is roaring in as I just came back from holidays, and there is a
couple issues with win32lib which I want to settle first, using probably all
available time - unless they prove trivil to settle, which I don't quite believe.
(Waiting for input from Derek (newUIObj()), Greg (xControls2 calling
validId({-1})) and perhaps Mike777 or Judith (semi crashes on recreating
controls)).
I'm currently enhancing getRect() for it to return the space taken by a menu
(item), including menu bars. This will
* fix a bug reported with setMousPointer()
* hopefully cure an old IDE issue with large fonts when the menu bar wraps
Written the code last night, as I have still some jet lag, but didn't test it
yet.

CChris

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu