Re: [PATCH] Fix Makefile.macosx for users without Xcode

[Kon Lovett]

i’ll try it, but probably not until the weekend

> On Feb 15, 2023, at 11:15 AM, Mario Domenech Goulart  
> wrote:
> 
> Hi Josh,
> 
> On Tue, 8 Mar 2022 08:27:41 -0500 josh  > wrote:
> 
>> Hello there, hope you're all well.
>> 
>> I recently ran into trouble building Chicken on my MacOS system (Big Sur
>> 11.2.3) due to issues with command-line tool paths. There was a change in
>> c6a6a26225620b566f8bc487cc4180de5a2a that assumed the user has Xcode
>> installed, and that the tools are within /Applications/Xcode.app/.
>> 
>> However, it's possible to install command-line tools on MacOS without Xcode
>> (if one tries to run e.g. `gcc` on a fresh MacOS install you'll be prompted
>> to do so), in which case the Makefile's assumptions are not sufficient. This
>> patch adds a check to see if Xcode is installed, and if not uses the tools
>> in /usr/bin instead.
>> 
>> (Please note that this is my first patch to Chicken, and first patch in
>> general :P, so my apologies if I'm missing anything. I'm also not familiar
>> with GNU's make so I hope the construct I chose is portable enough.)
>> 
>> Thank you all for your time and hard work!
> 
> Thanks for your patch.  Not sure if you got any feedback on it?  If not,
> apologies for the embarrassingly long time to reply.
> 
> The change looks sensible to me, but I don't have an OSX system to test
> it.
> 
> Any takers?
> 
> All the best.
> Mario
> -- 
> http://parenteses.org/mario

Re: SRFI 193 (Command lines) for Chicken

[Kon Lovett]

i will take a stab at some of these

> On Aug 8, 2020, at 5:14 AM, Lassi Kortela  wrote:
> 
> Hello,
> 
> SRFI 193 is in the last-call period before finalization. Here is an
> implementation for Chicken. I'd like to publish it as an egg. The API
> is trivial enough that if you like it, you may want it in core.
> 
> The code works as is, but has the following issues:
> 
> - It's Chicken 5 only. Could it be easily backported to 4?

yes

> 
> - It checks for the magic string "csi" to figure out whether running
>  in csi or in a standalone program compiled using csc. The check is
>  dodgy; what would be a proper way to do it?

csi adds feature identifiers at runtime: 
(http://wiki.call-cc.org/man/5/Module%20(chicken%20platform)#features)

csi always
chicken-script  when -ss, -sx, -s, -script

otherwise not the interpreter

(cond-expand
  (chicken-script   (main (command-line-arguments)) )
  (csi  (display “run it yourself”) (newline) )
  (else (main (command-line-arguments)) ) )


> 
> - Pathname handling is not cross-platform. It uses `string-append`
>  with "/" to build pathnames, and feeds the result to
>  `normalize-pathname` to resolve relative pathnames into absolute.
>  How does one get the host platform's directory separator, and would
>  there be cleaner ways to write the pathname parts in general?

(make-pathname "foo" “")=>  "foo/“

(make-pathname "foo” “bar") =>  “foo/bar“

- while (chicken pathname) knows the separator, it does not export ;-)

> 
> Thanks to anyone who can spare a moment to help a noob :)
> 
> ;;; --
> 
> (module srfi-193
>(command-line command-name command-args script-file script-directory)
> 
>  (cond-expand
>(chicken-5
> (import scheme (chicken base) (chicken module) (chicken pathname)
> (rename (only (chicken process-context)
>   current-directory
>   argv command-line-arguments program-name)
> (argv   chicken/argv)
> (command-line-arguments chicken/command-line-arguments)
> (program-name   chicken/program-name)
> 
>  ;;; Fundamental
> 
>  ;; csi -script  => "filename.scm"
>  ;; csi repl => #t
>  ;; exe from csc => #f
>  (define interpreted
>(let ((arg0 (car (chicken/argv
>  (and (equal? "csi" (pathname-file arg0))
>   (if (equal? "csi" (chicken/program-name)) #t
>   (chicken/program-name)
> 
>  (define (script-file)
>(and (string? interpreted)
> (normalize-pathname
>  (string-append (current-directory) "/" interpreted
> 
>  (define command-line
>(make-parameter (if (eqv? #t interpreted) '("")
>(cons (or (script-file) (chicken/program-name))
>  (chicken/command-line-arguments)
> 
>  ;;; Derived
> 
>  (define (command-name)
>(let ((file (car (command-line
>  (and (not (equal? "" file))
>   (pathname-file file
> 
>  (define (command-args)
>(cdr (command-line)))
> 
>  (define (script-directory)
>(let ((file (script-file)))
>  (and file (string-append (pathname-directory file) "/")
> 

irregex-match? & specialize question

[Kon Lovett]

= I must be missing something

cat >matches-prob-test.scm <<'HERE'
(import scheme)
(import (chicken irregex))

(define (uses-predicate str)
  (and
(string? str)
(irregex-match? '(: "foo") str) ) )

(print "uses-predicate: " (uses-predicate ""))
HERE

csc ./matches-prob-test.scm
./matches-prob-test
#uses-predicate: #f

csc -specialize ./matches-prob-test.scm
./matches-prob-test
#Error: unbound variable: and

Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling

[Kon Lovett]

attached is the compressed trunk

it uses the utf8 egg + a couple of my eggs

> On Jan 9, 2020, at 3:01 PM, Jeff Moon  wrote:
> 
> Kon,
> You noted in this thread that you had ported csv-xml for your own purposes.  
> Would you be willing to share your changes, or could we get this into the 
> released system?
> 
> Also, even though Ivan mentioned that the csv egg had been superseded, is 
> anybody interested in getting that ported to chicken 5?  I think it would be 
> helpful to users porting chicken 4 code to chicken 5 to be able to have this 
> there.
> 
> Thanks,
> Jeff
> 
> 

<>

Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling

[Kon Lovett]

> NOTE: Aside from the effort in porting the code there are still a few
> dependencies on eggs that have not been ported. Triming dependencies
> may eliminate some of these. A quick crude scan of use statements gave
> me this:
> 
> call-with-environment-variables
> csv
> csv-xml
> dot-locking
> foof-loop
> hostinfo
> pathname-expand
> ports
> regex-case
> rpc
> s11n
> sparse-vectors
> srfi-12
> srfi-19
> tcp

csv-xml ported - for my own purposes

srf-19 is waiting on srfi-29, which is waiting on me figuring out how to 
install bundles w/ .egg (custom build scripts, *nix & win, probably)

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

[Chicken-hackers] srfi-69 & keyword vs symbol

[Kon Lovett]

something like the attached?



hash-table-tests.scm.diff
Description: Binary data


srfi-69.scm.diff
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Regarding #1564: srfi-18: (mutex-unlock) Internal scheduler error

[Kon Lovett]

well, that shows me. ;-)

trying to track down why 

#497 $ chicken-install -r srfi-18
mapped (srfi-18) to ()
retrieving ...


> On Dec 2, 2018, at 10:42 AM, Kon Lovett  wrote:
> 
> C5 evicted srfi-18, along w/ srfi-1, 13, 14, & 69, to the egg store.
> 
> chicken-install -retrieve.
> 
>> On Dec 2, 2018, at 10:39 AM, Jörg F. Wittenberger 
>>  wrote:
>> 
>> Hi all,
>> 
>> when I tried to reply in a timely manner I apparently sent out a link to a 
>> broken file. Sorry for that.
>> 
>> Just wanted to see if I could create a patch for the current master.
>> 
>> For this I need srfi-18 egg source too.  Just I can't find it.
>> 
>> Jöry
>> 
>> On Nov 30 2018, Jörg F. Wittenberger wrote:
>> 
>>> Hello Megane,
>>> 
>>> On Nov 30 2018, megane wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Here's another version that crashes quickly with "very high
>>>> probability".
>>> ...
>>>>  24 Error: (mutex-unlock) Internal scheduler error: unknown thread state
>>>>  25#
>>>>  26ready
>>> 
>>> This bears an uncanny resemblance to scheduler issues I've been fighting a 
>>> long ago.
>>> 
>>> Too long to ago.
>>> 
>>>> --- A fix
>>>> 
>>>> Just allow the 'ready state for threads in mutex-unlock!
>>>> 
>>>> ...
>>>> Is this a correct fix?
>>> 
>>> 
>>> Too long ago.
>>> 
>>> But it feels wrong. We'd rather make sure there is no ready thread in the 
>>> queue waiting for a mutex in the first place.
>>> 
>>> Diffing the changes I maintained quite a while back 
>>> http://ball.askemos.org/Ad60e3fb123a79b2e5128915116b288f7/chicken-4.9.1-ball.tar.gz
>>>  you will find that I added a
>>> 
>>> ##sys#thread-clear-blocking-state!
>>> 
>>> Towards the end of scheduler.scm and used it for consistency whereever I 
>>> ran into not-so-clean unlocks.
>>> 
>>> Now this is still an invasive change. But looking at the source of 
>>> scheduler and srfi-18 in chicken 5 right now, I can't fight the feeling 
>>> that it is working around the missing changes at several places.
>>> 
>>> Best
>>> 
>>> /Jörg
>>> 
>>> 
>>> ___
>>> Chicken-hackers mailing list
>>> Chicken-hackers@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>>> 
>> 
>> ___
>> Chicken-hackers mailing list
>> Chicken-hackers@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> 

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

Re: [Chicken-hackers] Regarding #1564: srfi-18: (mutex-unlock) Internal scheduler error

[Kon Lovett]

C5 evicted srfi-18, along w/ srfi-1, 13, 14, & 69, to the egg store.

chicken-install -retrieve.

> On Dec 2, 2018, at 10:39 AM, Jörg F. Wittenberger 
>  wrote:
> 
> Hi all,
> 
> when I tried to reply in a timely manner I apparently sent out a link to a 
> broken file. Sorry for that.
> 
> Just wanted to see if I could create a patch for the current master.
> 
> For this I need srfi-18 egg source too.  Just I can't find it.
> 
> Jöry
> 
> On Nov 30 2018, Jörg F. Wittenberger wrote:
> 
>> Hello Megane,
>> 
>> On Nov 30 2018, megane wrote:
>> 
>>> Hi,
>>> 
>>> Here's another version that crashes quickly with "very high
>>> probability".
>> ...
>>>   24 Error: (mutex-unlock) Internal scheduler error: unknown thread state
>>>   25#
>>>   26ready
>> 
>> This bears an uncanny resemblance to scheduler issues I've been fighting a 
>> long ago.
>> 
>> Too long to ago.
>> 
>>> --- A fix
>>> 
>>> Just allow the 'ready state for threads in mutex-unlock!
>>> 
>>> ...
>>> Is this a correct fix?
>> 
>> 
>> Too long ago.
>> 
>> But it feels wrong. We'd rather make sure there is no ready thread in the 
>> queue waiting for a mutex in the first place.
>> 
>> Diffing the changes I maintained quite a while back 
>> http://ball.askemos.org/Ad60e3fb123a79b2e5128915116b288f7/chicken-4.9.1-ball.tar.gz
>>  you will find that I added a
>> 
>> ##sys#thread-clear-blocking-state!
>> 
>> Towards the end of scheduler.scm and used it for consistency whereever I ran 
>> into not-so-clean unlocks.
>> 
>> Now this is still an invasive change. But looking at the source of scheduler 
>> and srfi-18 in chicken 5 right now, I can't fight the feeling that it is 
>> working around the missing changes at several places.
>> 
>> Best
>> 
>> /Jörg
>> 
>> 
>> ___
>> Chicken-hackers mailing list
>> Chicken-hackers@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>> 
> 
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] CHICKEN 5 egg scheme-include install oddity

[Kon Lovett]

thank you for checking. i’ll look into it.

i use a lot of ‘ln -s’ to “mount" C4 vs C5. ex:

  ln -shf "${CHICKEN_PREFIX}/share/chicken" /usr/local/share/chicken
  ln -shf "${CHICKEN_PREFIX}/share/manual-labor-support" 
/usr/local/share/manual-labor-support
  ln -shf "${CHICKEN_PREFIX}/share/case-map-1.dat" 
/usr/local/share/case-map-1.dat
  ln -shf "${CHICKEN_PREFIX}/share/case-map-2.dat" 
/usr/local/share/case-map-2.dat

so reproducing could have some issues there. (hah, my /usr/local/share is a 
forest of symlinks, few of my design ;-)

> On Sep 23, 2018, at 2:35 AM, Peter Bex  wrote:
> 
> On Thu, Sep 20, 2018 at 09:40:11PM +1200, Evan Hanson wrote:
>> Hi Kon,
>> 
>> I haven't been able to reproduce this with a small test case or by using
>> the includes branch of fx-utils in SVN. What does `echo ,r | csi` say
>> for this CHICKEN installation?
> 
> I've also tried and failed to reproduce it.  As far as I know, the "5"
> should never appear in the path anyway, we only use the binary version
> when constructing paths, right?
> 
> Could you please try to delete your chicken installation, the
> chicken-install cache and try from scratch?
> 
> Cheers,
> Peter
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] CHICKEN 5 egg scheme-include install oddity

[Kon Lovett]

es
  srfi-0srfi-1srfi-10
  srfi-11   srfi-12   srfi-13
  srfi-14   srfi-15   srfi-16
  srfi-17   srfi-2srfi-23
  srfi-26   srfi-28   srfi-30
  srfi-31   srfi-39   srfi-4
  srfi-43   srfi-46   srfi-55
  srfi-6srfi-6srfi-61
  srfi-62   srfi-69   srfi-8
  srfi-9unix  x86-64


Machine type:   x86-64 (64-bit)
Software type:  unix
Software version:   macosx
Build platform: clang
Installation prefix:/usr/local/chicken/5
Extension installation location:/usr/local/chicken/5/lib/chicken/9
Extension path: (/usr/local/chicken/5/lib/chicken/9)
Include path:   (/usr/local/chicken/5/share/chicken 
/usr/local/chicken/5/lib/chicken/9)
Keyword style:  suffix
Symbol-table load:  1.39
  Avg bucket length:1.85
  Total symbol count:   4181
Memory: heap size is 4226064 bytes with 2853648 bytes currently in use
nursery size is 1048576 bytes, stack grows downward
Command line:   ("csi")

interrupts are enabled


> 
> Evan
> 
> On 2018-09-17 17:15, Kon Lovett wrote:
>> (install prefix for C5 is /usr/local/chicken/5)
>> 
>> the scheme-include install in /usr/local/chicken/5/5/share seems out-of-step 
>> w/ the binaries in /usr/local/chicken/5/lib, w/ the addition of an extra 
>> level ‘5’
>> 
>> not sure what i am doing wrong, if anything
>> 
>> — ~/.chicken-install/cache/fx-utils/fx-utils.install.sh --
>> 
>> #!/bin/sh
>> 
>> set -e
>> cd '/Users/klovett/.chicken-install/cache/fx-utils'
>> 
>> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
>> install -m644 
>> '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.static.o' 
>> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.o'
>> install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.link' 
>> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.link'
>> 
>> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
>> rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.so'
>> install -m755 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.so' 
>> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.so'
>> 
>> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
>> rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so'
>> install -m755 
>> '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.import.so' 
>> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so'
>> 
>> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
>> install -m644 
>> '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.types' 
>> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.types'
>> 
>> mkdir -p ${DESTDIR}'/usr/local/chicken/5/5/share'
>> install -m644 
>> '/Users/klovett/.chicken-install/cache/fx-utils/fx-inlines.scm' 
>> ${DESTDIR}'/usr/local/chicken/5/5/share'
>> 
>> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
>> rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.egg-info'
>> cat >${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.egg-info' 
>> <> ((installed-files
>>   "/usr/local/chicken/5/5/share/fx-inlines.scm"
>>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.o"
>>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.link"
>>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.so"
>>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.types"
>>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so")
>> (synopsis "fx utilities")
>> (version "4.0.0")
>> (category misc)
>> (author "[[kon lovett]]")
>> (license "BSD")
>> (test-dependencies test)
>> (components
>>   (scheme-include fx-inlines (files "fx-inlines.scm"))
>>   (extension
>> fx-utils
>> (types-file)
>> (csc-options "-O3" "-d1" "-local" "-no-procedure-checks"
>> ENDINFO
>> 
>> 
>> ___
>> Chicken-hackers mailing list
>> Chicken-hackers@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/chicken-hackers

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

Re: [Chicken-hackers] CHICKEN 5 egg scheme-include install oddity

[Kon Lovett]

-possibly useful information; hidden as a .egg comment

  (extension fx-utils
#;(inline-file)
(types-file)
;FIXME Error: (apply) bad argument type: #f
#;(component-dependencies fx-inlines)
(csc-options "-O3" "-d1" "-local" "-no-procedure-checks") )

> On Sep 17, 2018, at 5:15 PM, Kon Lovett  wrote:
> 
> (install prefix for C5 is /usr/local/chicken/5)
> 
> the scheme-include install in /usr/local/chicken/5/5/share seems out-of-step 
> w/ the binaries in /usr/local/chicken/5/lib, w/ the addition of an extra 
> level ‘5’
> 
> not sure what i am doing wrong, if anything
> 
> — ~/.chicken-install/cache/fx-utils/fx-utils.install.sh --
> 
> #!/bin/sh
> 
> set -e
> cd '/Users/klovett/.chicken-install/cache/fx-utils'
> 
> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
> install -m644 
> '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.static.o' 
> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.o'
> install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.link' 
> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.link'
> 
> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
> rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.so'
> install -m755 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.so' 
> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.so'
> 
> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
> rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so'
> install -m755 
> '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.import.so' 
> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so'
> 
> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
> install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.types' 
> ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.types'
> 
> mkdir -p ${DESTDIR}'/usr/local/chicken/5/5/share'
> install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-inlines.scm' 
> ${DESTDIR}'/usr/local/chicken/5/5/share'
> 
> mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
> rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.egg-info'
> cat >${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.egg-info' 
> < ((installed-files
>   "/usr/local/chicken/5/5/share/fx-inlines.scm"
>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.o"
>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.link"
>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.so"
>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.types"
>   "/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so")
> (synopsis "fx utilities")
> (version "4.0.0")
> (category misc)
> (author "[[kon lovett]]")
> (license "BSD")
> (test-dependencies test)
> (components
>   (scheme-include fx-inlines (files "fx-inlines.scm"))
>   (extension
> fx-utils
> (types-file)
> (csc-options "-O3" "-d1" "-local" "-no-procedure-checks"
> ENDINFO
> 


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

[Chicken-hackers] CHICKEN 5 egg scheme-include install oddity

[Kon Lovett]

(install prefix for C5 is /usr/local/chicken/5)

the scheme-include install in /usr/local/chicken/5/5/share seems out-of-step w/ 
the binaries in /usr/local/chicken/5/lib, w/ the addition of an extra level ‘5’

not sure what i am doing wrong, if anything

— ~/.chicken-install/cache/fx-utils/fx-utils.install.sh --

#!/bin/sh

set -e
cd '/Users/klovett/.chicken-install/cache/fx-utils'

mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
install -m644 
'/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.static.o' 
${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.o'
install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.link' 
${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.link'

mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.so'
install -m755 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.so' 
${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.so'

mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so'
install -m755 
'/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.import.so' 
${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.import.so'

mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-utils.types' 
${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.types'

mkdir -p ${DESTDIR}'/usr/local/chicken/5/5/share'
install -m644 '/Users/klovett/.chicken-install/cache/fx-utils/fx-inlines.scm' 
${DESTDIR}'/usr/local/chicken/5/5/share'

mkdir -p ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9'
rm -f ${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.egg-info'
cat >${DESTDIR}'/usr/local/chicken/5/lib/chicken/9/fx-utils.egg-info' 

[Chicken-hackers] build error w/ clang on macos

[Kon Lovett]

(sorry, under the weather, or i would investigate)

this doesn’t look right:

clang: error: unsupported option '-b undle -headerpad_max_install_names’

last commit in local repo is:

commit dc07113cf79a1930c6a109c738138dbea15afbc0 (HEAD -> master, 
origin/master, origin/HEAD)
Author: Peter Bex 
Date:   Sat Sep 1 18:33:59 2018 +0200

#512 $ build_chicken check

check build of version 5 master for macosx installing in /usr/local/chicken/5
C compiler C_COMPILER=clang CXX_COMPILER=clang
C compiler options -fno-strict-aliasing -fwrapv -fno-common -m64 -O3 
-fomit-frame-pointer -Wall -Wno-unused -Wno-uninitialized

cd tests; sh runtests.sh
 repository search path ...
(/usr/local/chicken/5/lib/chicken/9)
(PASS) (repository-path) contains something by default
 TOTALS: 
  1 tests completed in 0.885 seconds
  1 (100.00%) tests passed
  0 (0.00%) tests failed
/usr/bin/env 
DYLD_LIBRARY_PATH='/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/..'
 /Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/../chicken 
'sample-module.scm' -output-file 'sample-module.c' -dynamic -feature 
chicken-compile-shared -verbose -include-path 
/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/.. 
-consult-types-file ../types.db -ignore-repository -emit-import-library 
sample-module
generating import library `sample-module.import.scm' for module `sample-module' 
...
/usr/bin/env 
DYLD_LIBRARY_PATH='/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/..'
 'clang' 'sample-module.c' -o 'sample-module.o' -c  -fno-strict-aliasing 
-fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -m64 -DC_ENABLE_PTABLES 
-I/opt/local/include -I/usr/local/include -fno-strict-aliasing -fwrapv 
-fno-common -m64 -O3 -fomit-frame-pointer -Wall -Wno-unused -Wno-uninitialized 
-fPIC -DPIC -DC_SHARED 
-I/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/.. 
-I/usr/local/chicken/5/include/chicken
rm sample-module.c
/usr/bin/env 
DYLD_LIBRARY_PATH='/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/..'
 'clang' 'sample-module.o' -o 'sample-module.so' -m64 -L/opt/local/lib 
-L/usr/local/lib "-bundle -headerpad_max_install_names" 
-L/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/.. 
-L/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/.. 
-lchicken -lm
clang: error: unsupported option '-b undle -headerpad_max_install_names'

Error: shell command terminated with non-zero exit status 256: /usr/bin/env 
DYLD_LIBRARY_PATH='/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/..'
 'clang' 'sample-module.o' -o 'sample-module.so' -m64 -L/opt/local/lib 
-L/usr/local/lib "-bundle -headerpad_max_install_names" 
-L/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/.. 
-L/Users/klovett/Workspace/LISP/Scheme/Chicken/chicken-core-5/tests/.. 
-lchicken -lm
make: *** [check] Error 1


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

Re: [Chicken-hackers] Egg plan for 5?

[Kon Lovett]

> On Jan 4, 2018, at 7:36 PM, Dan Leslie  wrote:
> 
> I figured I had simply not been thorough enough; you folks do a
> fantastic job in documenting your efforts. Thank-you for pointing me in
> the right direction!
> 
>> By the way, if there are features you'd like that would make things
>> easier for Geiser, don't hesitate to open an enhancement ticket on
>> bugs.call-cc.org.
> 
> Thanks to the chicken-doc and apropos eggs most of the available
> features in Geiser are available; with Chicken 4 the manipulation of
> modules was a little cumbersome because it had to disect the module name
> from the eval output when inspecting a symbol. That falls apart whenever
> someone decides to import a module using a prefix that has a # in it;
> which apparently happens enough to result in bug reports. However, the
> recent versions of the apropos egg are clever enough to neatly
> undecorate symbols and inform where they come from, and Geiser leverages
> this behaviour.

sadly all it does is 

(nams (string-split (symbol->string sym) "#" #t)

for the identifiers and the definition of a "gensym"

'(: bos (>= 2 any) (>= 2 num) eos) 'utf8

so not clever ;-)

(& i need to add a mode to modify/stop the “pretty” behavior)

> 
> Thanks to dumb-jump now having Scheme support, there's Good Enough
> jump-to-definition support in Emacs that I'm generally satisfied; but
> if Chicken could decompile a symbol, and/or show what file/line it was
> built in... Wish lists. :D
> 
> -Dan
> 
> 
> On Fri, 5 Jan 2018 15:39:25 +1300
> Evan Hanson  wrote:
> 
>> Hey Dan,
>> 
>> There is thorough -- but provisional! -- documentation here:
>> 
>>  https://wiki.call-cc.org/man/5/Extensions#format-of-the-egg-description-file
>> 
>> That page will obviously change as development continues, but it
>> should include enough information to get you started, or at least to
>> help you figure out the next question to ask.
>> 
>> By the way, if there are features you'd like that would make things
>> easier for Geiser, don't hesitate to open an enhancement ticket on
>> bugs.call-cc.org.
>> 
>> Cheers,
>> 
>> Evan
> 
> 
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] What to do with CHICKEN 4.13/4.12.1 release/snapshot?

[Kon Lovett]

CHICKEN 4 LTS

create a "Foundation for the Continuation” to support all NEKCIHCs

> On Nov 5, 2017, at 3:09 PM, Evan Hanson  wrote:
> 
> Hi all,
> 
> I think we should:
> 
> 0.) Fix 1399 in master and chicken-5.
> 1.) Tag 4.13.0rc1.
> 1.1, ...) Iterate until we have a good RC, release as 4.13.0.
> 2.) Rename master to chicken-4.
> 3.) Rename chicken-5 to master.
> 
> From that point on we develop on master while chicken-4 gets security
> patches only. We continue to support 4.13.X with security fixes until
> 5.0.0 is released + N days, however long we'd like to offer users time
> to upgrade. One year seems like a reasonable length of time to me.
> 
> Cheers,
> 
> Evan
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] "simple" SRFI 12 condition api

[Kon Lovett]

> On May 25, 2017, at 5:03 AM, Peter Bex <pe...@more-magic.net> wrote:
> 
> Hi, Kon!
> 
> I wonder if you still remember the mail below.  It's over 2 years ago,
> but finally I've made a patch to include a procedure like make-condition+
> in CHICKEN 5.
> 
> See http://lists.gnu.org/archive/html/chicken-hackers/2017-05/msg00071.html
> 
> Now, there's a small discussion about what to do with the format, because
> condition->list uses a slightly different list representation of
> conditions.  The idea is to unify the format, but we're wondering whether
> we should change condition->list to match the new constructor, or vice
> versa.  See the follow-up posts for this discussion.

In this instance I think convenience should override precedence. So 
condition->list should return a plist. I think the plist makes a more 
user-friendly literal.

I know the goal is not to add to the core but maybe adding the plist <-> alist 
conversion functions from list-utils eggs would help. (Unless Chicken 5 is 
removing the symbol property-list.)

> 
> Do you have an opinion on the matter?  Feel free to mail to
> chicken-hackers!
> 
> Cheers,
> Peter
> 
> On Fri, Aug 29, 2014 at 10:14:14AM -0700, Kon Lovett wrote:
>> On Aug 29, 2014, at 9:47 AM, Peter Bex <peter@xs4all.nl> wrote:
>> 
>>> On Fri, Aug 29, 2014 at 09:21:24AM -0700, Kon Lovett wrote:
>>>> (Sorry to drag this out)
>>>> 
>>>> Something like:
>>>> 
>>>>(make-condition+ `(exn location loc message "foo") `(i/o) `(file 
>>>> filename ,file))
>>> 
>>> Ah, condition-utils already has it!
>>> 
>>> Well, maybe we can pull that into core?
>> 
>> After a little code review & public discussion. (make-*-condition(+) is from 
>> '09 but I only fixed today the requirement of a 'message property for 'exn; 
>> the Error printer wants a message property.)
>> 
>> This is another example of a (widely?) useful extension but not really 
>> "core" functionality, i.e. not primitive in the foundation sense.
>> 
>> But encouraging (by facilitating?) people to throw exceptions is a worthy 
>> goal. The trick is getting them to document said exceptions ;-)
>> 
>> Maybe there is the start of a heuristic for deciding what should be "core" 
>> above & beyond what is primitive: does it encourage a desired coding style.
>> 
>> BTW, condition-utils also has syntax for creating condition predicates & 
>> property getters. However the memeoized nature of the implementation might 
>> be a turn-off.
>> 
>>> 
>>> Cheers,
>>> Peter
>>> -- 
>>> http://www.more-magic.net


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

Re: [Chicken-hackers] egg make depends

[Kon Lovett]

 On Dec 22, 2014, at 12:29 PM, Alexej Magura agm2...@gmail.com wrote:
 
 Not sure if this is the right mailing list.

chicken-us...@nongnu.org mailto:chicken-us...@nongnu.org might be better 
since this is more about usage

 
 Is there a reason why egg meta files don't support make depends, that is 
 depends that are only required during the installation/build process and can 
 be removed afterwards?

Like, say, ‘setup-helper’ ;-) 

An annotation like (setup-depends (setup-helper 1.5.2”)) will be ignored but 
serve as documentation; the meta file is just an a-list s-expression. With the 
dependency still needed in ‘depends’.

Would chicken-install remove the setup-dependencies fetched, rather than 
discovered, as part of the install?

 
 Like what if an egg's setup file needs another egg.  Should this dependency 
 just get placed under depends like other dependencies even though it's only 
 required for the installation?

For now, yes.
  -- 
 Alexej Magura
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

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

Re: [Chicken-hackers] [PATCH] Remove several deprecated things which should not cause too much trouble

[Kon Lovett]

On Jun 9, 2014, at 1:36 PM, Peter Bex peter@xs4all.nl wrote:

 On Mon, Jun 09, 2014 at 01:33:58PM -0700, Kon Lovett wrote:
 
 On Jun 7, 2014, at 1:25 PM, Peter Bex peter@xs4all.nl wrote:
 
 Hi all,
 
 The attached patch removes the majority of things that were officially
 deprecated or just marked OBSOLETE.  This is just the low-hanging fruit.
 
 The removal of C_enumerate_symbols breaks the apropos egg.
 
 Can you move the implementation of this procecure into that egg,

Yes.

 or
 implement it some other way?  It's been deprecated for quite a while.

Must not be paying attention. Only marked in the source?

 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net


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

Re: [Chicken-hackers] [Chicken-announce] CHICKEN 4.9.0rc1 is available

[Kon Lovett]

Operating system: MacOS 10.9.2
Hardware platform: x86-64,
C Compiler: clang-503.0.40
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes


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

Re: [Chicken-hackers] [PATCH] Fix finalizer issue on non-GCable constants

[Kon Lovett]

On Mar 17, 2014, at 1:38 PM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 The attached patch fixes the problem from subject, as described here:
 http://lists.nongnu.org/archive/html/chicken-users/2014-03/msg00088.html
 
 It also cleans up the code a little bit by re-using well-named C
 functions instead of repeating the same inline and C preprocessor-heavy
 checks which required comments to make sense of them.
 
 Felix has provided feedback on this patch, and it has been tested by
 Pluijzer.

passes check on MacOS 10.9.2, Apple LLVM version 5.1 (clang-503.0.38) , x86_64

(had to reject the Acknowledgements edit though)

 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Don-t-fire-finalizers-on-compiled-non-GCable-constan.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] [Chicken-users] Testers wanted; iOS patch

[Kon Lovett]

On Mar 15, 2014, at 4:41 AM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 Attached is a patch by Bevuta which Felix sent last X-mas.  It adds
 rudimentary support for iOS through a target Makefile.  I've so far been
 unable to test this because I don't have an iOS device.  I don't have
 access to a Mac, so I'm unable to verify that this patch even builds.
 
 I've asked Moritz, but he's extremely busy these days, so perhaps
 someone else is able to test this patch in the meanwhile?  I think
 it's best if two people who know about OS X/iOS check the patch.
 
 If nobody responds within a week, I'm going to go ahead and start the
 release process for 4.9.0, because it's not so critical that we can't
 make a release without this patch (but it would be nice if we can
 include it).

Looks like tcp.scm has moved past the state when the patch was created. Needs 
3-way  manual resolution.

If I am to be one of the two then my suggestion is to begin the release process 
w/o this patch. Don't believe I will be able to generate a test case that soon. 
(Sorry, have looming releases.)

 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Added-basic-iOS-support.patch___
 Chicken-users mailing list
 chicken-us...@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-hackers] [PATCH] Fix reexports with renaming in import libraries

[Kon Lovett]

On Feb 23, 2014, at 4:14 AM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 Felix has put in some time to help us fix #219, and I think it would be
 nice to get this into 4.9.0.  The fix is really rather simple.  For more
 info see the ticket and the commit message.
 
 This is basically the fix Felix attached to the ticket, but I've added
 the tests to the Windows batch script as well, and removed some trailing
 whitespace.

Passes check w/ MacOS 10.9

 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Attempt-to-fix-219-where-renamed-reexports-are-not-c.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] [PATCH] Fix isnormal() on Mingw, restore tests (fixing #1062 properly)

[Kon Lovett]

On Feb 23, 2014, at 4:48 AM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 While investigating how to make isnormal() work on Solaris (but before
 figuring out we need to define __C99FEATURES__), I came across an
 alternate solution involving __builting_isnormal, which apparently
 is a GCC builtin that performs the same function as the isnormal()
 macro defined in math.h.
 
 This builtin seems to work properly on Mingw, so I think it's safe
 to undefine the broken isnormal and replace it with the builtin one

Passes check w/ MacOS 10.9

 on Windows.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Fix-isnormal-problem-on-MingW-by-using-gcc-builtin-i.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] [PATCH] Quote $(MAKE) invocations

[Kon Lovett]

On Feb 20, 2014, at 5:20 PM, Mario Domenech Goulart mario.goul...@gmail.com 
wrote:

 Hi,
 
 Please, review the attached patch.

Passed MacOS 10.9.1 x86-64 clang 5.0

 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 0001-Quote-MAKE-invocations.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

[Chicken-hackers] [PATCH] macosx has strlcpy strlcat

[Kon Lovett]

Another is the BSD family



0001-macosx-has-strlcpy-strlcat.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Simplify header file inclusion

[Kon Lovett]

On Nov 24, 2013, at 11:48 AM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 Initially I wanted to keep this patch until after 4.9.0 was released,
 but I figured what the hell, we'll need to go through a release
 candidate cycle anyway and this patch isn't *that* risky, but it
 cleans up things considerably (should also lower build times somewhat).
 
 The patch simply rearranges some header files and simplifies
 several .scm files as many headers are unnecessary since they
 they already are included by chicken.h.  I also got rid of several
 messy preprocessor conditionals.  All of them are well-reasoned out,
 as indicated by the commit message (which may be a bit terse, so if
 you want me to expand upon it, just ask here).
 
 Basically this shuffles some stuff around, it doesn't change anything
 fundamentally.  I just took a hard look at what headers ended up being
 included unconditionally in some places, and removed all of the
 #ifdef-hedged instances of inclusion of the same header.
 
 I've tested on Linux, NetBSD, Haiku, cygwin, mingw and mingw-msys.

Successfully built  ran check target on:

Version 4.8.3 (rev 6ca6044)
macosx-unix-clang-x86-64 [ 64bit manyargs dload ptables ]

Darwin kurashiki 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 
2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64

 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Simplify-handling-of-header-file-inclusion.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-hackers] expand seems not to keep the promise made in the manual

[Kon Lovett]

On May 23, 2013, at 3:32 AM, Peter Bex peter@xs4all.nl wrote:

 On Thu, May 23, 2013 at 11:59:44AM +0200, Christian Kellermann wrote:
 Hi Joerg!
 
 * Jörg F. Wittenberger joerg.wittenber...@softeyes.net [130523 11:51]:
 Citing the manual
 
 procedure(expand X)/procedure
 
 If {{X}} is a macro-form, expand the macro (and repeat expansion
 until expression is a non-macro form).  Returns the resulting expression.
 
 I think this is just wrong in the documentation. What you probably
 want is expand* from the expand-full egg.
 

I wrote expand-full for debugging my macros. That is why it installs a csi 
command. I never thought of it as useful in macro writing.

I need to change the documentation to note the limitations so people do not 
waste their time.

 Indeed.  However, it has to be noted that this egg is fundamentally
 broken: it has no access to the syntactic environment, so it can never
 do a proper job.  A trivial example of this kind of breakage follows:
 
 (let-syntax ((foo (syntax-rules () ((_ x) x (expand* '(foo 1))) =
 (foo 1)
 
 Hairier macros which contain renamed identifiers will also break.
 Actually, I've never found any use for expand-full except the most
 trivial of macros (the kind where you don't tend to need expand in
 the first place).
 
 I don't think this is fixable, but I'd love to be proven wrong.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

[Chicken-hackers] [PATCH] runtime.c: stop clang warnings

[Kon Lovett]

Hi,

The attached stops warnings from the clang compiler. The format-string / 
argument changes I think have merit. The unused return value  no return value 
just stop warnings w/o any other worth.



fix_clang_warnings.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Ignore -rpath for mingw macosx

[Kon Lovett]

Attached is a patch that ignores the '-rpath directory' option for mingw  
macosx; MacOS X ld doesn't understand '-R'. (Sorry, sent to wrong list 
initially.)



ignore_rpath_for_macosx.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] fix for blob read syntax manual entry

[Kon Lovett]

Hi,

This was just bugging me.



fix_blob_read_syntax.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Request to edit manual Foreign type specifiers

[Kon Lovett]

Hi Folks,

I would like to edit the Foreign type specifiers manual section so  
pointer entries follow the optional attribute convention introduced  
by '[nonnull-] c-string*'. I will also add a general note about the  
pointer passing/return #f - NULL conversion.


In keeping with the spirit above specifiers like unsigned-integer  
will become [unsigned-] integer.


Let me know if any issues,

Thank you,
Kon


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

Re: [Chicken-hackers] The use of the null-pointer and null-pointer? procedures

[Kon Lovett]

On May 11, 2011, at 8:14 AM, Peter Bex wrote:


On Wed, May 11, 2011 at 08:21:32AM -0400, Felix wrote:

On Wed, May 11, 2011 at 05:25:12AM -0400, Felix wrote:

I was wondering what use does (null-pointer?) has.


Historical. I will deprecate.


Thanks, Felix.  I noticed the documentation says
Another way to say (address-pointer 0).  Should the address- 
pointer

procedure return #f when given 0?


No, otherwise you couldn't create a pointer object containing a NULL
pointer... :-) I think we can expect a user to be able to code this.


I understand that this wouldn't be possible. But what is the reason
this has to be possible, considering null pointers are represented
as #f everywhere else?  For consistency it would make sense to return
#f here too, but of course you could also argue that it would be more
consistent to always return a pointer...


Possible to apply the #f representation for NULL across all pointer  
procedures but is this really the problem? The original issue was  
brought on by the lack of instructive examples in the manual for FFI  
use.


Suggest leaving lolevel alone and add to the FFI documentation instead.



Ah well

Cheers,
Peter
--
http://sjamaan.ath.cx
--
The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music.
-- Donald Knuth

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



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

[Chicken-hackers] Using new chicken-install -reinstall

[Kon Lovett]

Hi,

The new chicken-install -reinstall option in the experimental branch  
requires an addition to the extension infolist (.setup-info file  
contents), the egg-name-and-version. Below is a program which will,  
given an existing Chicken install  a local copy of the SVN egg repo,  
add the missing datum. Any eggs installed with the new, experimental,  
chicken-install will have the new info.


(use extras files posix srfi-1 miscmacros)

;; Write the elements of the list `ls' to the output-port or output- 
file, using

;; the `writer' procedure. `writer' is a (procedure (* output-port)).
;;
;; (add `newline?' param for write #\newline after every element?)
(define (write-file ls #!optional (file-or-port (current-output-port))  
(writer write))

  (let ((port (if (port? file-or-port) file-or-port
(open-output-file file-or-port) ) ) )
(dynamic-wind
  void
  (lambda () (for-each (cut writer  port) ls))
  (lambda () (unless (port? file-or-port) (close-output-port  
port ) )


#;
(define (write-file ls #!optional (file-or-port (current-output-port))  
(writer write))

  (let* ((port (if (port? file-or-port) file-or-port
 (open-output-file file-or-port) ) )
 (closit (lambda () (unless (port? file-or-port) (close- 
output-port port )

(handle-exceptions exn
(begin (closit) (abort exn))
  (for-each (cut writer  port) ls))
(closit) ) )

(define-constant +info-extn+ setup-info)

(define (info-filenames #!optional (dir (repository-path)))
  (let ((cd (current-directory)))
(current-directory dir)
(begin0
  (map pathname-file (glob (make-pathname '() * +info-extn+)))
  (current-directory cd) ) ) )

(define (get-info eggnam #!optional (dir (repository-path)))
  (car (read-file (make-pathname dir eggnam +info-extn+))) )

(define (put-info info eggnam #!optional (dir (repository-path)))
  (let ((tmpfil (create-temporary-file)))
(write-file (list info) tmpfil)
(file-move tmpfil (make-pathname dir eggnam +info-extn+) #t) ) )

; no protection against existing egg-name-and-version
(define (update-info info eggnam)
  (and-let* ((ver (assq 'version info)))
(cons
  `(egg-name-and-version (,eggnam ,(-string (cadr ver
  info)) )

(define (update-info-file eggnam #!optional (dir (repository-path)))
  (and-let* ((info (update-info (get-info eggnam dir) eggnam)))
(put-info info eggnam dir)
#t ) )

(define (main #!optional (svnroot (cadr (argv
  (let ((eggdir (make-pathname `(,svnroot chicken-eggs release  
4) ))

(repdir (repository-path)) )
(newline)
(print Local SVN Repository:  eggdir)
(print Installed Egg Repository:  repdir)
(newline)
(let* ((egdrnms (directory eggdir))
   (siflnms (info-filenames repdir))
   (eggnams (lset-intersection string=? egdrnms siflnms)) )
(for-each
  (lambda (eggnam)
(print eggnam)
(unless (update-info-file eggnam)
  (print Warning: no version detected) ) )
  eggnams ) ) ) )

#; ;remove this line when compiling,  otherwise just load into csi   
invoke main w/ a dirname

(main)


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

Re: [Chicken-hackers] Remove of egg version from subversion query

[Kon Lovett]

Hello folks,

Thank you for the response. I have moved uuid-ossp 1.22 to 1.2.2.; 22  
 4 so small problem there.


(The test used `testbase', which I haven't gotten around to  
converting, so it was incomplete anyway.)


Best Wishes,
Kon


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

Re: [Chicken-hackers] blob-literal read syntax

[Kon Lovett]

On Oct 18, 2010, at 1:16 AM, Felix wrote:


Hello!

I have added read-syntax for blob-literals and currently use

 #{hex...}

Since this may block the use of #{ ... } for user-defined read- 
syntax,

I want to ask if perhaps another syntax might be preferrable. Any
ideas? Or would the syntax above be ok for such a built-in object.


I would rather '#{' not be used. (I want it ;-)

Suggest '#bv([0..255]...)'.

I am guessing that the motivation for a blob sexp is something like  
QD serialization or debugging and not necessarily a prime human  
editable form.





cheers,
felix

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


Best Wishes,
Kon



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

[Chicken-hackers] Re: Backdoor GPL in message-digest

[Kon Lovett]

On Aug 23, 2010, at 7:48 AM, Jim Ursetto wrote:


Kon,

The addition of the GPL-3 format-compiler-base to check-errors in SVN
r19227 has tainted amb, apropos, box, directory-utils,
err5rs-arithmetic, list-utils, locale, lookup-table, macosx, mailbox,
message-digest, moremacros, multimethod, pandora,
procedure-description, remote-mailbox, sqlite3, srfi-19, srfi-27,
srfi-29, srfi-41, srfi-45, stack, string-utils, symbol-utils, and
synch.


Assume a component of package A uses something that is GPL'ed, but no  
other component in that package uses the GPL tainted component (it is  
just along for the ride). Then all components of package A are  
tainted?


Doesn't this reasoning lead to the absurd conclusion that any software  
installation with a GPL'ed component somewhere is tainted? Or is it  
just the act of packaging? Then the Chicken svn repo is tainted since  
it can be delivered as a package?


Obviously I don't know what constitutes a package in this context.



Primarily we are concerned about message-digest because it taints sha1
and from there, qwiki and http-session.  For example, see
http://tests.call-cc.org/2010/08/23/salmonella-report/dep-graphs/qwiki.png
.

We'd appreciate it if you would remove this dependency.


Done.



Thanks,
Jim


Best Wishes,
Kon

P.S. err5rs-arithmetic is not released  multimethod probably will  
never have a release.


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

Re: [Chicken-hackers] Re: Backdoor GPL in message-digest

[Kon Lovett]

The below is moot since I moved everything into own eggs, where they  
belong anyway.


On Aug 23, 2010, at 12:52 PM, Peter Bex wrote:


On Mon, Aug 23, 2010 at 12:43:21PM -0700, Kon Lovett wrote:

Assume a component of package A uses something that is GPL'ed, but no
other component in that package uses the GPL tainted component (it is
just along for the ride). Then all components of package A are
tainted?


If package A is one binary or a set of binaries that always get linked
to a package using it, then it does.  It's called a derivative work.
Yes, this is insane.


Yeah, I deliberately did not mention linked, only packaged, since  
I don't see them as the same thing. W/O the benefit of hazy memory I  
seem to recall that the GPL talks of link editing but it may also  
speak of anything distributed, linked or not.


In the format-compiler-base used by error-utils in check-errors  
situation nothing got linked, only packaged. Unless errorf is  
actually used then no linkage occurs. (And, at the time, the only  
module using errorf was simple-units.)


I'm just saying that in the check-errors package none of the other  
modules were actually exposed to the contagion from the GPL tainted  
error-utils.


snip

Best Wishes,
Kon


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

Re: [Chicken-hackers] cond-expand and macros

[Kon Lovett]

On Nov 20, 2009, at 10:05 AM, Thomas Bushnell BSG wrote:


On Thu, 2009-11-19 at 18:33 -0800, Kon Lovett wrote:

Features are converted to keywords. The colon suffix is just the
default read/print form; #:keyword is the context-independent form.


The manual needs to document this; right now, one might have thought
they were ordinary symbols given every example and description in the
manual.


Please submit a bug report.




'cond-expand' uses a function that ensures the tested symbol is a
keyword, so 'foo'  '#:foo' are legal.

That the expansion-environment of a 'syntax-rules' transformer  
doesn't

recognize 'cond-expand' is a different problem. (Note that 'syntax-
rules' in Chicken 3 is not a core expander.)


So the bug is more or less that the self-evaluating nature of keywords
doesn't work in the meta-environment for macro expansion, I assume.


No, they are ordinary symbols (assuming the keyword read syntax is not  
present). The proffered symbol is converted to a keyword before  
comparison with the set of features. But this is performed by a  
procedure not the macro expander.


The self-evaluating nature of keywords works in macros AFAIK.


(Certainly that it goes differently in Chicken3+syntax-case is no
mystery, since the old syntax-case egg needed to provide its own
implementation of cond-expand anyway.)

Thomas




Best Wishes,
Kon




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

Re: [Chicken-hackers] cond-expand and macros

[Kon Lovett]

On Nov 19, 2009, at 4:45 PM, Thomas Bushnell BSG wrote:


Ok, so this is too weird by half.

When I do (register-feature! 'foo), then the feature that is  
registered

is foo:, despite what the actual manual says.  And then, for some
baroque reason, cond-expand matches foo and foo: (even though there is
no foo feature registered, since it's actually foo:) and then,  
inside
the context of a syntax-rules, suddenly cond-expand *doesn't* match  
foo,

though it still matches foo:.

Can I cry foul?  Why doesn't register-feature! simply register the
feature specified without this on-again-off-again colon magic?  What  
is
the point of adding a colon in the first place to the symbol name?   
Why

is it magically removed again sometimes?


Features are converted to keywords. The colon suffix is just the  
default read/print form; #:keyword is the context-independent form.


'cond-expand' uses a function that ensures the tested symbol is a  
keyword, so 'foo'  '#:foo' are legal.


That the expansion-environment of a 'syntax-rules' transformer doesn't  
recognize 'cond-expand' is a different problem. (Note that 'syntax- 
rules' in Chicken 3 is not a core expander.)




Thomas


On Thu, 2009-11-19 at 19:27 -0500, John Cowan wrote:

Thomas Bushnell BSG scripsit:


The following code does not work:

(define-syntax foo
 (syntax-rules ()
   ((_)
(cond-expand
 (chicken (display all good\n))
(foo)



Calling (features) shows that the feature name is chicken:, not
chicken.  If you change the above to reference chicken:, all is  
well.

This is not backward compatible and is still probably a bug, but at
least it's a simple bug.

On the other hand, (cond-expand (chicken (display all good\n)))  
does

output all good right away.






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


Best Wishes,
Kon




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

Re: [Chicken-hackers] cond-expand and macros

[Kon Lovett]

On Nov 19, 2009, at 7:15 PM, John Cowan wrote:


Kon Lovett scripsit:


'cond-expand' uses a function that ensures the tested symbol is a
keyword, so 'foo'  '#:foo' are legal.


Fair enough.  But in Chicken 4 syntax-rules macros, the non-keyword  
form

doesn't match, only the keyword form.  That makes no sense.  It's not
that cond-expand as a whole isn't being recognized, because it is;
it throws an error because there is no match.


My hypothesis (I didn't check) is the non-keyword symbol is run thru a  
hygiene regimen; keywords cannot be identifiers so exempt. Maybe:


(syntax-rules (foo)
((_ ?x ?y)
(cond-expand
(foo ...

might do something useful.



--
The serene chaos that is Courage, and the phenomenon   co...@ccil.org
of Unopened Consciousness have been known to theJohn Cowan
Great World eons longer than Extaboulism.
Why is that? the woman inquired.
Because I just made that word up, the Master said wisely.
   --Kehlog Albran, The Profit http://www.ccil.org/~cowan


Best Wishes,
Kon




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

[Chicken-hackers] Re: [Chicken-users] Bignums in core

[Kon Lovett]

Hi,

Personally I want a core Chicken with a component orientation towards  
the major sub-systems. I mean pluggable  composable string, number,  
gc, concurrency, file components; not to be construed as an exhaustive  
list.


I see Chicken at an architectural cross-roads. Rather than pilling  
capability into the core perhaps we should consider something that  
qualifies as it's all chickens down.


Best Wishes,
Kon

P.S.

People may notice that a perfectly good regular expression system was  
swapped for another. The motivation was not the push it off the  
table capability of Alex's irregex compared with PCRE but the desire  
to rid the core of an external dependency.


(DO NOT read this as a criticism of irregex. I like the sexp regexp  
formula. Only a cautionary tale.)




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

Re: [Chicken-hackers] too many core modules?

[Kon Lovett]

On Sep 1, 2009, at 12:57 AM, felix winkelmann wrote:


Hello!


It's probably just me, but if I have to write (use ports files
data-structures utils extras) one more
time, I'll go crazy.

I think the splitting up of the extras unit was done haphazardly. It
doesn't really give any
benefit to split up the library fo chicken extensions, since loading
one or two eggs will drag in
most of them anyway. I think it's ok to keep the SRFIs separate.


Personally I would like to go further in splitting files (Unit library  
itself is kinda unwieldy), creating units like 'pathname' and  
'system'. (Already mentioned by John Cowan as I was babbling.)




Therefore I'd like to introduce a new library unit (say
chicken-stuff [*]) that for the time
being just loads the other units and provides the necessary imports.
Nothing else
will be changed, with the exception of the manual. We can provide a  
placeholder
extension for pre 4.1.6 chickens (just like Mario did for the  
files unit).


Is it ok to make this change, or does somebody see a problem with  
this?


The creation of a compound module for a convenient Chicken Utility  
Library to head-off a dive into insanity seems necessary.


I do want to endorse the suggestion by Alex for an '(extend  
MODULE ...)' form; I build these manually. Would a consumer need to  
'require-library' to get the binary of the extended module or just  
require the extending module or both? Should extending a subset of a  
module and/or renaming/prefixing the identifiers be supported?





cheers,
felix

[*] a lame name - any suggestions are welcome


Hum, John's roaster is cute.




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


Best Wishes,
Kon





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

Re: [Chicken-hackers] parallel build failure

[Kon Lovett]

On Apr 13, 2009, at 11:00 AM, Jim Ursetto wrote:

On Mon, Apr 13, 2009 at 6:00 AM, felix winkelmann  
bunny...@gmail.com wrote:

On Mon, Apr 13, 2009 at 12:09 PM, Marijn Schouten (hkBst)
I got a report today that chicken-4.0.0 fails and that it is  
probably a parallel

build failure[1].



Don't use parallel builds.


Well, that's one option :) Parallel builds at -j2 have always worked
for me but there has been an intermittent failure issue for several
months; it always happens with setup-download, so I believe the
problem lies with a missing dependency there.  I will try to take a
look at this, Marijn.  I haven't yet because at -j2 I can simply
restart the build and it always works.


Yes, there is a missing dependency. I noticed it when working on setup- 
api but never bothered to look into it. Just typed  '!!ret'.





Jim


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


Best Wishes,
Kon




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

Re: [Chicken-hackers] Unit files

[Kon Lovett]

On Sep 19, 2008, at 6:38 AM, Mario Domenech Goulart wrote:


Hi Kon.

On Tue, 16 Sep 2008 16:16:56 -0700 Kon Lovett [EMAIL PROTECTED]  
wrote:



On Sep 16, 2008, at 4:06 PM, Ivan Raikov wrote:


 Yes, we are way overdue for a new release. I had to make some fixes
to the MinGW build last week, but now I think I am ready to make the
release, so I will merge trunk with the prerelease branch, and
probably I will make a new release by the end of the week.


Thank you Ivan. I was the one who introduced the dependency since a
number of eggs would not compile  moved too quickly.


Can't the uri egg use the files unit only when the chicken version is
equal or greater than 3.4.0?


Done. Release 3.405

snip



Best wishes.
Mario


Best Wishes,
Kon




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

Re: [Chicken-hackers] Unit files

[Kon Lovett]

On Sep 16, 2008, at 4:06 PM, Ivan Raikov wrote:



Hi Mario,

  Yes, we are way overdue for a new release. I had to make some fixes
to the MinGW build last week, but now I think I am ready to make the
release, so I will merge trunk with the prerelease branch, and
probably I will make a new release by the end of the week.

   -Ivan


Thank you Ivan. I was the one who introduced the dependency since a  
number of eggs would not compile  moved too quickly.





Mario Domenech Goulart [EMAIL PROTECTED] writes:


Hi folks.

Our latest release is 3.3.0, which doesn't provide the unit `files'.
At least one egg from the release/3 repo requires `files' (uri), so,
when you try to use the uri egg with the latest chicken it fails
because the `files' unit doesn't exist.

Furthermore, the current User's Manual provides documentation for the
unit `files'. That's confusing, even if the main page of the manual
states it's for 3.3.6, which can only be obtained via svn (i.e., the
manual is for a chicken version that has not been released yet).

I think the simplest fix for this is to make a new release.

What do you think?



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


Best Wishes,
Kon




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

Re: [Chicken-hackers] srfi-13 %string-copy speedup

[Kon Lovett]

On Mar 6, 2008, at 10:52 AM, Jim Ursetto wrote:

Core hackers, consider the attached srfi-13 patch which speeds up % 
string-copy!
by using an inline C_substring_copy (something that I guess has  
been noted

and planned for a while).

I saw a 1.5x speedup when concatenating 1 million 1-byte strings and
a 10x speedup for concatenating 15 one-million-byte strings.

Speedwise, this brings string-concatenate up to par with string- 
append,
without the argument limit.srfi-13- 
copy.txt___

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


Thank you, applied in chicken/trunk.

Best Wishes,
Kon




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

Re: [Chicken-hackers] Re: repository branching

[Kon Lovett]

On Feb 26, 2008, at 5:26 AM, felix winkelmann wrote:


Hi!


Regarding the repository question:

I'm getting bored.


I sympathize.

But the suggestion of specific version info in .meta is probably  
good. So would be a common version format - suggest #.#.# since it is  
very common  used by chicken itself.


So .meta can have:

(needs (chicken 3.*.*) foo (bar 1.2.3) (baz 2.3.*))

This doesn't mean = but = which is why the wildcards.

The .setup has something similar but by then it too late for chicken- 
setup to do anything about it except complain.




I propose someone comes up with an exact specification of
an alternative solution. We have one now that sort of works and
it will not be changed incrementally. I suggest we start from
scratch, get it working and switch over to a completely new
approach.

I don't want to fiddle with the current system and recommend
to others not to do so and instead fix everything from the ground
up. I personally don't want to invest any more time in repo
reorganization, I just want to keep the old stuff working. I have
implemented a significant part of the current mess and will
try my best to keep it working until someone else takes over
with a new system, for which I can disclaim all repsonsibility.


cheers,
felix


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


Best Wishes,
Kon




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

Re: [Chicken-hackers] TCP speedup

[Kon Lovett]

On Feb 26, 2008, at 2:30 AM, Jim Ursetto wrote:


Hi core hackers,

Please consider this TCP patch, which speeds up the output port a  
LOT; the

larger the write, the bigger the speedup.

snip

I will apply this if no one has objections.

Best Wishes,
Kon




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

Re: [Chicken-hackers] Hackathon roundup

[Kon Lovett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Feb 25, 2008, at 2:45 AM, Peter Bex wrote:


Hello everyone,

This weekend's hackathon was a great success.  Fun was had by all,  
and lots
of work got done.  Most importantly, a number of new people have  
become

more active in the project.

Summary
---

We have accomplished the following things:

- About twenty eggs got their old-style HTML documentation  
translated to

   the wiki format.


Thanks to everyone for all the work. I just wish test- 
infrastructure wasn't translated since it is obsolete. The current  
is testbase.


- We managed to break the wiki a couple of times, resulting in  
improvements

   to svnwiki.
- New syntax for documenting eggs in the wiki was implemented
   (http://chicken.wiki.br/wiki-syntax-chicken).
- We worked on Chicken tutorials for 'blub' programmers, for several
   values of 'blub': Ruby, Python and PHP.  A Chicken for Java  
tutorial

   is currently in the works, too.
- A document about how to hack on Chicken's core and the release  
process

   is currently underway.
- The eggs for release 2 of Chicken have found their way from the
   toplevel directory of the repository to the release/2 subdirectory,
   resulting in a clearer layout  of the repos.
- A number of programs on the Great Language Shootout game at
   http://shootout.alioth.debian.org/ have been improved so that  
Chicken

   will get a fairer comparison to other languages who have been
   spending more time on optimizing their shootout programs.

As you can see, the results are quite impressive.  I would like to  
thank

everyone who participated and made this possible!

What's next?


The hackathon may be over, but work will continue.  We should keep up
the momentum that we have gained during the hackathon and continue  
working

on the things to do.  There are still lots of eggs with old-style HTML
documentation.  These need to be translated to wiki syntax.  It should
be possible to automatically convert the eggdoc documentation, so  
these

are not our priority right now.  Furthermore, the
chicken-for-blub-programmers documents can use some attention of  
'blub'

language experts.

But most important of all, feel free to work on whatever *you* find
interesting and fun, to improve Chicken even more!

Thanks again, everyone!

Cheers,
Peter
--
http://sjamaan.ath.cx
--
The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
-- Donald Knuth
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Best Wishes,
Kon


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iEYEARECAAYFAkfC0FMACgkQJJNoeGe+5O7kvwCfcjBPDAJ1kDlYS0gBrMgGOfuv
p4oAn2XQsnHDIi5VXhnjwBg+19LSzUvK
=G7HU
-END PGP SIGNATURE-


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

Re: [Chicken-hackers] Hackathon roundup

[Kon Lovett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Feb 25, 2008, at 7:37 AM, Peter Bex wrote:


On Mon, Feb 25, 2008 at 06:27:31AM -0800, Kon Lovett wrote:

Thanks to everyone for all the work. I just wish test-
infrastructure wasn't translated since it is obsolete. The current
is testbase.


Even obsolete stuff should be moved to the wiki.  Everything in one
place means everything in one place.


wish wasn't meant to be interpreted as a condemnation of the  
central documentation repository principle. wish meant if one had  
to be chosen I wish it was testbase.



  If testbase is *that* obsolete,
we should just 'svn rm' it.


testbase is not obsolete, test-infrastructure is. AFAIK no  
decision on when to remove the Unsupported or redundant eggs has  
been made.




Cheers,
Peter
--
http://sjamaan.ath.cx
--
The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
-- Donald Knuth
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Best Wishes,
Kon


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iEYEARECAAYFAkfC4rkACgkQJJNoeGe+5O5c/ACfdeaglmTSpjRVqyYcOx/FlE59
MM8AnR+4M0B5QOlq5iHuOSokFEI7f99n
=vhqt
-END PGP SIGNATURE-


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

Re: [Chicken-hackers] base64.egg bug

[Kon Lovett]

On Feb 22, 2008, at 7:17 AM, Jim Bailey wrote:


Hello,

I just set up a new machine with chicken 3.0 and noticed a bug in
the latest base64.egg.

When it got ported to C one important case got ignored - decoding a
blank string should result in a blank string. Currently the code tries
to (string-ref  -2) which fails, obviously.

I have attached an updated version of base64.scm which handles this
case.


Checked in.



Kind Regards,

Jimbase64.scm___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers


Best Wishes,
Kon




PGP.sig
Description: This is a digitally signed message part
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] ANN: new features in release 3

[Kon Lovett]

Hi Folks,

Unit extras:

The SRFI-69 hash-table is extended w/ SRFI-90'ish features. (No weak- 
keys/values since no weak-references, yet.)


New companions to any?: none?, always?, never?.

New left-section  right-section (sort of a variadic curry).

Unit library:

New flonum-print-precision (useful when you want something more  
than 16 digits - or less).


Unit posix:

time-string has an optional 'strftime' format string.

New string-time - uses 'strptime' so Unix only.

Best Wishes,
Kon




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

Re: [Chicken-hackers] ANN: new features in release 3

[Kon Lovett]

On Feb 11, 2008, at 1:17 PM, Graham Fawcett wrote:


On Feb 11, 2008 4:01 PM, Kon Lovett [EMAIL PROTECTED] wrote:


New left-section  right-section (sort of a variadic curry).


Very cool. I, for one, bow to our new higher-order overlords.


Not mine. Stolen from SRFI-41. Still cool, though ;)



Thanks,
Graham


Best Wishes,
Kon




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

Re: [Chicken-hackers] What happened to -strict-letrecs?

[Kon Lovett]

On Feb 9, 2008, at 10:18 AM, John Cowan wrote:


Alex Shinn scripsit:


The current letrec behavior is a perfectly compliant
interpretation of R5RS.  There is another compliant
interpretation which would signal an error in some cases.


Here are the relevant bits of code from SISC's r5rs_pitfall.scm:

snip

r5rs_pitfall is in the repo but not part of runtests.

cd ${directory-path-to}/chicken-eggs/chicken/trunk/tests
../csi -R syntax-case -script r5rs_pitfalls.scm
Failure: 1.1, expected '0', got '1'.
Failure: 1.2, expected '#t', got '#f'.
Passed: 1.3
Passed: 2.1
Passed: 3.1
Passed: 3.2
Passed: 3.3
Passed: 3.4
Passed: 4.1
Passed: 4.2
Passed: 4.3
Passed: 5.1
Passed: 5.2
Passed: 5.3
Passed: 6.1
Passed: 7.1
Passed: 7.2
Passed: 7.3
Passed: 7.4
Passed: 8.1
Passed: 8.2
Failure: 8.3, expected '1', got '2'.
Map is call/cc safe, but probably not tail recursive or inefficient.

Best Wishes,
Kon




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

Re: [Chicken-hackers] multiple issues in embedded PCRE

[Kon Lovett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Nov 13, 2007, at 3:52 PM, Marijn Schouten (hkBst) wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Cowan wrote:

Marijn Schouten (hkBst) scripsit:

chicken ships its own copy of libpcre which has multiple  
vulnerabilities

http://secunia.com/advisories/27543/.


It should definitely be upgraded, then.

Issues such as this one are the reason why local copies of  
libraries are bad.
Currently there doesn't seem to be an option to build against the  
system

libraries though.


On non-Gentoo systems, it's extremely common for buggy and vulnerable
libraries to remain around for years.  Since that's the normal  
case, we
adapt to it by packaging pcre.  Indeed, that's the only way to  
guarantee
i14y, since sufficiently old libpcre's don't even expose the same  
API.


Even if that is so, you don't solve any problems by adding another
installation of libpcre. It doesn't make any system libraries go  
away. What it

*does* do is create another point of failure.


There is not ... another installation of libpcre. The only  
libraries Chicken installs are libchicken  libuchicken.




I also don't see what good it does to interoperability. The only  
thing you're
doing is deciding where the breakage is by doing the upgrading of  
libpcre when

*you* choose.


I think John means between the Chicken regex unit implementation   
the pcre api. I doubt he was referring to other programs.




Anyway, I'm sure this won't have convinced you, so please consider  
adding a
configure switch to build with system libpcre instead of the  
shipped one.


Thank you,

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOjilp/VmCx0OL2wRAi8oAJ45kuEB2Df7QpdS0Hk5PfFc1MKjdwCeIive
y4GhbreU60qWKVJYfsL9TOc=
=QMFQ
-END PGP SIGNATURE-


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


Best Wishes,
Kon


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iEYEARECAAYFAkc6PoIACgkQJJNoeGe+5O6hSACdHjUopj7yQiUkhcedD48e0PQ4
7GUAn1CdfUbqNrBfGbN9ie/seVtyWueW
=w+U8
-END PGP SIGNATURE-


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

[Chicken-hackers] Anyone remember why 'set-user-id!' 'set-group-id!' are deprecated?

[Kon Lovett]

Hi,

I cannot find a reference to why the posix unit procedures 'set-user- 
id!'  'set-group-id!' were deprecated. Does anyone know?


Best Wishes,
Kon



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

[Chicken-hackers] Missing PCRE 7.4 files

[Kon Lovett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The snapshot is missing:

pcre_newline.c
pcre_ucp_searchfuncs.c
ucptable.h
pcre_chartables.c

But they seem to be in the repo.

?,
Kon

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iEYEARECAAYFAkb/scgACgkQJJNoeGe+5O7VnQCcDWiuXfXrRoyyNrLPSkMtI7UX
m2YAni4CeTf0chJNIWL39qEn/ZiH27Y+
=qGjm
-END PGP SIGNATURE-


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

Re: [Chicken-hackers] new release policy

[Kon Lovett]

On Sep 2, 2007, at 12:46 AM, Elf wrote:



what platforms and do we have testsuites available?


See chicken-eggs/chicken/trunk/tests. Not a testsuite like those  
found in many eggs but what I run (along w/ the benchmarks) as a  
build checkout.



  i'm willing to help write
a testsuite to make this job feasible.


Via the Chicken svn-wiki we should be able to have test contributions  
for the core  eggs. What we do not have is the machinery to  
recognize when the unit in question, or a dependency, has changed,  
the test harness and configuration required, collect the various  
tests  attach to the required test harness, run the combined suite 
(s), and report the results.


Bits  pieces of the above exist but as whole, well, there is a project.

Best Wishes,
Kon



-elf


snip


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

Re: [Chicken-hackers] (software-type) on *BSD

[Kon Lovett]

On Aug 6, 2007, at 5:18 AM, foobar wrote:


felix winkelmann schrieb:

Should it return 'unix or 'bsd ?



If bsd is returned then by this logic MacOS X should also return bsd.  
Leave it as unix.


So far 'software-version' is specific enough for compile time  
distinctions (except for Windows). Actual release information might  
be useful.


In practice I use a mixture of C defines and Scheme features.

Best Wishes,
Kon



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

Re: [Chicken-hackers] Re: .exports not renamed w/ CMake Windows build

[Kon Lovett]

On Jan 8, 2007, at 9:43 AM, Brandon J. Van Every wrote:
snip


I'm asking whether lumping all these under one name is a basic  
error of Chicken's design.  What do Chicken programs do when ported  
from Unix to Windows?  Just gratuitously fail, looking for exports  
that aren't there?  I'll wager that historically, programs haven't  
been ported from Unix to Windows very often, so the issue hasn't  
come up.


I see at least 2 correct philosophies for dealing with this:

1) keep the .exports different.  Make the programmer deal with  
whether they're using posixunix, posixwin, pcre, pregexp, or  
regexunix.


2) make the .exports identical in content, and create stub  
functions for whatever's missing, perhaps giving a diagnostic  
error.  That way when the program dies, at least the user knows why.


In reaction to this, you might say, Well I just want it to be (use  
posix) and (use regex).  I don't want to type anything new /  
different than what's in the manual, I just want it to work.  But  
it isn't going to work.  At least not generally speaking; it only  
works if you happen to use a supported subset.  I am saying, the  
programmer has to deal with the available functions somewhere,  
somehow, if the program is to be well-behaved.


Yes. Use the supported subset. Use #+windows/#+unix otherwise.

The design flaw would be separate code for each platform.




Cheers,
Brandon Van Every



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




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