Re: [Chicken-users] Regex fail?

[Peter Bex]

On Thu, Oct 29, 2015 at 09:12:44PM -0700, Matt Welland wrote:
> (string-match "^([^\n]*)(\n.*|).*$" "This\nis \n")
> => #f
> 
> Using Ruby as comparison:
> 
> irb(main):001:0> "This\nis \n".match(/^([^\n]*)(\n.*|)$/)
> => #

Interesting!  This seems to be a problem in the way string->sre works:

#;10> (string->sre  "^([^\n]*)(\n.*|).*$")
(seq bos (submatch (* (/ #\xe000 #\x10 #\vtab #\xd7ff #\null #\tab))) 
(submatch (or (seq "\n" (* nonl)) epsilon)) (* nonl) eos)

Note the nonl, which the manual states is equivalent to ".", but of
course nonl means "no newline".

You can work around this by using the SRE directly:

#;12> (irregex-match '(seq bos (submatch (* (~ "\n"))) (submatch (or (seq "\n" 
(* any)) epsilon)) (* any) eos)  "This\nis \n")
#
#;13> (irregex-match-substring #12 1)
"This"
#;14> (irregex-match-substring #12 2)
"\nis \n"

Fixing this in irregex would be trivial, but I guess there's a *reason*
why "." is considered the same as 'nonl.

Maybe Alex can give us some info about why this is the case?  I think this
may have something to do with the multi-line / single-line distinction
(which, to be honest, I never really understood).

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Which API to use (llrb)?

[Jörg F. Wittenberger]

Am 29.10.2015 um 20:57 schrieb John Cowan:
> "Jörg F. Wittenberger" scripsit:
> 
>> However when it comes to `fold` I'm not sure if it is better to follow
>> the srfi-1 argument order (combiner-initial-set) or the srfi-69 style
>> order (set-combiner-initial).
> 
> SRFI-1 rules, SRFI-69 (in this respect) drools.  The in-progress SRFI
> 125 uses SRFI 1 order.

I haven't been aware of SRFI-125 nor srfi-114 so far.

Taking hints I'll simply allow both orderings for the -table interfaces
and go with the srfi-1 ordering for immutable trees.

Furthermore the llrb-treetype had already grown in the meantime to
include a key? argument.  Adding one more for the here unused hash
function make it equivalent to srfi-114's comparators.  Thus I better
use the latter.

John, does a chicken implementation already exist?

Thanks

/Jörg

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Which API to use (llrb)?

[John Cowan]

"Jörg F. Wittenberger" scripsit:

> John, does a chicken implementation already exist?

SRFI 125 is only implemented for Larceny, but the code's pretty portable.
I'm in the process of replacing SRFI 114 with the simpler SRFI 128, so
hold off on that for a bit.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Evolutionary psychology is the theory that men are nothing but horn-dogs,
and that women only want them for their money.  --Susan McCarthy (adapted)

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Which API to use (llrb)?

[Jörg F. Wittenberger]

Am 29.10.2015 um 20:49 schrieb Dan Leslie:
> Whatever works with the doto macro?

Looks like `doto` expects it's first `var` argument to be mutable and
returns the same reference.  This would argue in favor of the srfi-69
ordering.  (Which is available via the -table API atop.)

However those "binding-set"s are immutable.  To work with the `doto`
macro the latter would have to return the result of the application of
`proc` instead of `var`.


> Sent from my BlackBerry 10 smartphone.
>   Original Message  
> From: Jörg F. Wittenberger
> Sent: Thursday, October 29, 2015 12:47 PM
> To: chicken-users
> Subject: [Chicken-users] Which API to use (llrb)?
> 
> Hi all,
> 
> I did some more refinements to the LLRB-code I recently posted here.
> 
> However I got stuck on the inability to decide which API to use.
> 
> The idea is to have a type "binding-set" (is there a better name?) as an
> alternative t alists.
> 
> However when it comes to `fold` I'm not sure if it is better to follow
> the srfi-1 argument order (combiner-initial-set) or the srfi-69 style
> order (set-combiner-initial).
> 
> At one hand trying to be a "drop-in" for lists it would better not
> change the argument order wrt. srfi-1.
> 
> However the fold procedure from srfi-1 takes two arguments, the element
> (for alists the key-value-pair) and the accumulated value. The fold
> operation for "binding-set" is to be called with three arguments, key,
> value and result-so-far. Just like srfi-69's hash-table-fold.
> 
> Therefore being 100% drop-in is not possible anyway. Therefore it might
> be better to follow to srfi-69 order.
> 
> So which line of reasoning to follow? Which one of the following is
> APIs "better"? Any reasoning I'm not aware of?
> 
> Best
> 
> /Jörg
> 
> 
> A: srfi-69
> 
> (binding-set-fold set proc nil)
> 
> {{Proc}} must be a procedure of three arguments. It is invoked for
> each element with the key, value and the accumulated value (nil for
> the first element).
> 
> B: srfi-1
> 
> (binding-set-fold proc nil set)
> 
> {{Proc}} must be a procedure of three arguments. It is invoked for
> each element with the key, value and the accumulated value (nil for
> the first element).
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] strange IUP canvas behavior - mouse clicks returning bad value

[Matt Gushee]

Hi, Matt--

On Thu, Oct 29, 2015 at 10:24 PM, Matt Welland 
wrote:

> I'm not sure how to narrow this problem down but I'd like to start with a
> fresh build of chicken / IUP. However that process never seems to go well
> for me.
>

What part doesn't go well? Is it the IUP egg, or the IUP library itself?
I've rarely had trouble with the former, often with the latter ...


> Has anyone recently installed the chicken IUP egg on 64bit Ubuntu 15.04 or
> a recent Debian and if so would you be so kind as to share your recipe for
> success?
>

I've been meaning for a while to update my IUP library. I've had some
struggles with that in the past, and have worked out some solutions ...
however, I'm on Arch Linux, so the issues may or may not be similar. At any
rate, once I've done that I'll post a report in case it is useful.

--
Matt Gushee
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Regex fail?

[John Cowan]

Peter Bex scripsit:

> Note the nonl, which the manual states is equivalent to ".", but of
> course nonl means "no newline".

Dot in regular expressions has *always* meant "match any character but a
newline".  It doesn't come up that much in Unix commands, which typically
process their input line by line anyway.  But if you look at the Posix
definition or the Perl one, you see that dot is indeed equivalent to "nonl".
Indeed, "nonl" exists in order to have an SRE equivalent for dot.

> Maybe Alex can give us some info about why this is the case?  I think this
> may have something to do with the multi-line / single-line distinction
> (which, to be honest, I never really understood).

Multi-line and single-line mean totally different things: you can use one
of them or both or neither.  Multi-line mode means that ^ and $ will match
the beginning and end of a line as well as the beginning and the end of
the string.  In non-multi-line mode, they match only the beginning and
the end of the string.  Single-line mode means that dot matches newline;
non-single-line mode means that it does not.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
You know, you haven't stopped talking since I came here. You must
have been vaccinated with a phonograph needle.
--Rufus T. Firefly

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users