[Chicken-hackers] mutex-lock! in types.db

[Jörg F . Wittenberger]

it appears that the mutex-lock! declaration in types.db is not
currect.

The second optional argument according to my reading of may be
either a thread (struct) or #f ; however types.db only expects
a thread.


best

/Jörg






...

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

Re: [Chicken-hackers] [Chicken-users] using types

[megane]

Jörg F. Wittenberger writes:

> On Feb 21 2013, Jörg F. Wittenberger wrote:
>
>>Somehow I can't verify that my type declarations are actually
>>effective.
>
>
> I've been able to verify that my .types files are not ever consulted.
>
> Using strace I found that the "foo.types" file is searched for in
>
> stat("/usr/lib/chicken/6/foo.types", 0x7fffc1895400) = -1 ENOENT (No such 
> file or directory)
>
> But since that's not an extension but just a simple module, which is
> part of a larger program, there is no good reason to ever install
> the .types file in the repository.
>
> To deal with the issue I tried to use -setup-mode.  No effect at all.
>
> Further it seem to be the case that CHICKEN_REPOSITORY must be s imple
> directory and may not be some colon-separated path.
>
> At this moment I don't see any solution how to make chicken read
> the .types files it produced *within* a single directory.
>
> How would I do that?
>
> Thanks a lot!
>

Could you try if this [1] patch is of help. It essentially makes the
compiler to search for .types files from each path supplied with
-include-path.

Footnotes: 
[1]  http://bugs.call-cc.org/ticket/938


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

Re: [Chicken-hackers] [patch] utils: qs not escaping pipes

[Michele La Monaca]

The provided patch is my attempt at improving qs. The new
backward-compatible signature is:

(define (qs str #!optional (platform (build-platform)) (escape-mode #f))

If escape-mode is false (default) qs acts in "quote-mode":
double-quotes for mingw32, single-quotes for other platforms.

> (display (qs "foo bar" 'not-mingw32))
'foo bar'

> (display (qs "foo bar" 'mingw32))
"foo bar"

if a single/double quote is present, it is escaped this way respectively:

> (display (qs "foo'bar" 'not-mingw32))
'foo'\''bar'

> (display (qs "foo\"bar" 'mingw32))
"foo"""bar"

If a '%' sign is present in mingw32 an exception is raised since
expansion of variables (e.g %PATH%) is not prevented by double-quotes.


In escape-mode strings are backslash-escaped (not-mingw32 platforms)
or caret-escaped (mingw32):

> (display (qs "foo&bar" 'not-mingw32 #t))
foo\&bar

> (display (qs "foo&bar" 'mingw32 #t))
foo^&bar

While backslash-escaping is equivalent to its corresponding quoting,
the same is not true for caret-escaping. Depending on the context one
is more appropriate than the other. AFAICT the "general" rule is to
use double-quoting for pathnames and caret-escaping for textual
strings. For example, caret-escaping is your friend when using the
echo command:

# echo ^%PATH^%
%PATH%

As regarding backslash-escaping I changed the list of escaped
characters in this way:

1) added the characters '|' '=' '^' ','
2) removed the charater '%'. I don't see a good reason to escape it. Am I wrong?
3) removed a non ASCII character (0xb4). Why it was there?

If you see missteps or ways to improve please raise your hands. As you
may guess, this is really a tricky subject.

Regards,
Michele


On Tue, Feb 19, 2013 at 11:07 PM, Michele La Monaca
 wrote:
> On Tue, Feb 19, 2013 at 10:09 PM, Peter Bex  wrote:
>> Why?  What does it buy us?  The only reason 'qs' is available is to
>> safely escape arbitrary strings for the shell.
>
> Suppose you want to implement some kind of command-line completion. In
> this case backslash-escaping is a better fit, I think.
>
>> I think the new version does a good job at this.
>>
>> Why should we provide a known-broken version?
>
> Backslash-escaping is not broken per se. Let's say it's more difficult
> to implement and the current implementation is not just there.
>
> Regards,
> Michele


0001-tentative-improved-qs-function.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers