Re: [Chicken-hackers] pop3 support TOP command?
Alex Shinn writes: > On Mon, Mar 17, 2014 at 6:49 AM, John J Foerch > wrote: > > Very nice! I see that it has SSL support as well. Would you be at all > inclined to making some of hato's modules, like hato-pop, > independently > available? > > Yes, the plan is to make all of hato's modules available > as R7RS modules. > Sounds great, I look forward to it. -- John Foerch ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pop3 support TOP command?
On Mon, Mar 17, 2014 at 6:49 AM, John J Foerch wrote: > Very nice! I see that it has SSL support as well. Would you be at all > inclined to making some of hato's modules, like hato-pop, independently > available? > Yes, the plan is to make all of hato's modules available as R7RS modules. > John Foerch > > Alex Shinn writes: > > Hato supports pop3-top: > > > > https://code.google.com/p/hato/ > > > > On Sun, Mar 16, 2014 at 5:52 AM, John Cowan > > wrote: > > > > John J Foerch scripsit: > > > > > > > Maybe this would be an idea for a new egg to supersede the pop3 > egg. > > I > > > would be glad to hear anybody's thoughts on this. > > > > > > [1]: http://docs.racket-lang.org/net/pop3.html > > > > > > Sounds like an excellent idea, if you or someone else wanted to > tackle > > it. > > > > -- > > XQuery Blueberry DOM John Cowan > > Entity parser dot-com co...@ccil.org > > Abstract schemata http://www.ccil.org/~cowan > > XPointer errata > > Infoset Unicode BOM --Richard Tobin > > > > ___ > > 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 > ___ 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
On Mar 17, 2014, at 1:38 PM, Peter Bex 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-fuse
Turns out there's some other bug (though in fuse.scm) Am 17.03.2014 15:55, schrieb "Jörg F. Wittenberger": Hi Evan, I'm running up against some crazy segfault. It happens under some locally reproducibly circumstances, though I do not yet understand it. Nevertheless, I'm concerned with the inconsistent related use of fuse_file_info_fh's result. As far as I see it's only set in fuse_open_callback to the result of object-evict of the users value. In fuse_release_callback it is used as - correspondingly - expected by first calling object-unevict on fuse_file_info_fh's return value. However fuse_read_callback and fuse_write_callback both simply pass the result up to the user code. This strikes me as wrong, isn't it? These concerns remain valid IMHO. Aren't they? However my problem was caused by fuse_create_callback, which indeed seems broken. According to fuse.h " If the file does not exist, first create it with the specified mode, and then open it" I understand that the create procedure is supposed to return a file handle, not simply a error code. That is the wrapper in fuse.scm should set the info file handle like this: (define-callback (fuse_create_callback (c-string path) (mode_t mode) (fuse_file_info fi)) int (let ((v ((current-filesystem-callback 7) path mode))) (fuse_file_info_fh_set! fi (object-evict v)) (callback-result 'create v))) With this change the code already works much better. ;-) Unfortunately: that won't fix my problem. I'm using (as per documented recommendation) integer values as handles anyway. I would assume them to not be damaged that way. (BEWARE: that's a wild guess.) The segfault I'm getting however is always when the return value fuse_file_info_fh is accessed. I tried to wrap an object-unevict around it - same. Just that the segfault is then no longer in my code, but right in the object-unevict I inserted into fuse.scm. Continuing my wild guesswork: the stack trace from gdb points right into srfi-69 code and up the call chain the next I'm seeing is the "(let copy ...)" loop from object-unevict. The offending call seems to be hash-table-ref/default in the cond within that "copy" loop. Sorry for this noise. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Fix finalizer issue on non-GCable constants
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. Cheers, Peter -- http://www.more-magic.net >From 7110da9beb8e6ada2a070dc07acdeadd3df8ad4e Mon Sep 17 00:00:00 2001 From: Peter Bex Date: Mon, 17 Mar 2014 21:30:39 +0100 Subject: [PATCH] Don't fire finalizers on compiled, non-GCable constants (reported by "Pluijzer") --- NEWS |3 +++ manual/Acknowledgements | 38 +++--- runtime.c | 45 + tests/runtests.bat|4 tests/runtests.sh |2 ++ tests/test-finalizers.scm | 15 +++ 6 files changed, 60 insertions(+), 47 deletions(-) diff --git a/NEWS b/NEWS index e967a15..b7120df 100644 --- a/NEWS +++ b/NEWS @@ -24,6 +24,9 @@ - Runtime system - The procedure trace buffer has been made resizable. - C_zap_strings and ##sys#zap-strings (undocumented) have been deprecated. + - finalizers on constants are ignored in compiled code because compiled +constants are never GCed (before, the finalizer would be incorrectly +invoked after the first GC). (Reported by "Pluijzer") - Tools - csc: "-z origin" is now passed as a linker option on FreeBSD when diff --git a/manual/Acknowledgements b/manual/Acknowledgements index cbf9d5f..14283c2 100644 --- a/manual/Acknowledgements +++ b/manual/Acknowledgements @@ -35,25 +35,25 @@ Eric Merrit, Perry Metzger, Scott G. Miller, Mikael, Karel Miklav, Bruce Mitchener, Fadi Moukayed, Chris Moline, Eric E. Moore, Julian Morrison, Dan Muresan, David N. Murray, Timo Myyrä, "nicktick", Lars Nilsson, Ian Oversby, "o.t.", Gene Pavlovsky, Levi Pearson, Jeronimo -Pellegrini, Nicolas Pelletier, Derrell Piper, Carlos Pita, Robin Lee -Powell, Alan Post, "Pupeno", Davide Puricelli, "presto", Doug Quale, -Imran Rafique, Eric Raible, Ivan Raikov, Santosh Rajan, Joel Reymont, -"rivo", Chris Roberts, Eric Rochester, Paul Romanchenko, Andreas -Rottman, David Rush, Lars Rustemeier, Daniel Sadilek, Otavio Salvador, -Burton Samograd, "Sandro", "satori", Aleksej Saushev, Oskar Schirmer, -Reed Sheridan, Ronald Schröder, Spencer Schumann, Ivan Shcheklein, -Alex Shinn, Ivan Shmakov, "Shmul", Tony Sidaway, Jeffrey B. Siegal, -Andrey Sidorenko, Michele Simionato, Iruata Souza, Volker Stolz, Jon -Strait, Dorai Sitaram, Robert Skeels, Jason Songhurst, Clifford Stein, -David Steiner, Sunnan, Zbigniew Szadkowski, Rick Taube, Nathan Thern, -Mike Thomas, Minh Thu, Christian Tismer, Andre van Tonder, John Tobey, -Henrik Tramberend, Vladimir Tsichevsky, James Ursetto, Neil van Dyke, -Sam Varner, Taylor Venable, Sander Vesik, Jaques Vidrine, Panagiotis -Vossos, Shawn Wagner, Peter Wang, Ed Watkeys, Brad Watson, Thomas -Weidner, Göran Weinholt, Matthew Welland, Drake Wilson, Jörg -Wittenberger, Peter Wright, Mark Wutka, Adam Young, Richard Zidlicky, -Houman Zolfaghari and Florian Zumbiehl for bug-fixes, tips and -suggestions. +Pellegrini, Nicolas Pelletier, Derrell Piper, Carlos Pita, "Pluijzer", +Robin Lee Powell, Alan Post, "Pupeno", Davide Puricelli, "presto", +Doug Quale, Imran Rafique, Eric Raible, Ivan Raikov, Santosh Rajan, +Joel Reymont, "rivo", Chris Roberts, Eric Rochester, Paul Romanchenko, +Andreas Rottman, David Rush, Lars Rustemeier, Daniel Sadilek, Otavio +Salvador, Burton Samograd, "Sandro", "satori", Aleksej Saushev, Oskar +Schirmer, Reed Sheridan, Ronald Schröder, Spencer Schumann, Ivan +Shcheklein, Alex Shinn, Ivan Shmakov, "Shmul", Tony Sidaway, Jeffrey +B. Siegal, Andrey Sidorenko, Michele Simionato, Iruata Souza, Volker +Stolz, Jon Strait, Dorai Sitaram, Robert Skeels, Jason Songhurst, +Clifford Stein, David Steiner, Sunnan, Zbigniew Szadkowski, Rick +Taube, Nathan Thern, Mike Thomas, Minh Thu, Christian Tismer, Andre +van Tonder, John Tobey, Henrik Tramberend, Vladimir Tsichevsky, James +Ursetto, Neil van Dyke, Sam Varner, Taylor Venable, Sander Vesik, +Jaques Vidrine, Panagiotis Vossos, Shawn Wagner, Peter Wang, Ed +Watkeys, Brad Watson, Thomas Weidner, Göran Weinholt, Matthew Welland, +Drake Wilson, Jörg Wittenberger, Peter Wright, Mark Wutka, Adam Young, +Richard Zidlicky, Houman Zolfaghari and Florian Zumbiehl for +bug-fixes, tips and suggestions. Special thanks to Brandon van Every for contributing the (now defunct) [[http://www.cmake.org|CMake]] support and for helping with Windows diff --git a/runtime.c b/runtime.c index fdbc4d0..35dcf2b 100644 --- a/runtime.c +++ b/runtime.c @@ -497,6 +497,7 @@ static void C_fcall really_mark(C_word *x) C_regparm; static WEAK_TABLE_ENTRY *C_fcall lookup_weak_table_entry(C_word item, C_word container) C_
Re: [Chicken-hackers] chicken-fuse
Hi Evan, I'm running up against some crazy segfault. It happens under some locally reproducibly circumstances, though I do not yet understand it. Nevertheless, I'm concerned with the inconsistent related use of fuse_file_info_fh's result. As far as I see it's only set in fuse_open_callback to the result of object-evict of the users value. In fuse_release_callback it is used as - correspondingly - expected by first calling object-unevict on fuse_file_info_fh's return value. However fuse_read_callback and fuse_write_callback both simply pass the result up to the user code. This strikes me as wrong, isn't it? Unfortunately: that won't fix my problem. I'm using (as per documented recommendation) integer values as handles anyway. I would assume them to not be damaged that way. (BEWARE: that's a wild guess.) The segfault I'm getting however is always when the return value fuse_file_info_fh is accessed. I tried to wrap an object-unevict around it - same. Just that the segfault is then no longer in my code, but right in the object-unevict I inserted into fuse.scm. Continuing my wild guesswork: the stack trace from gdb points right into srfi-69 code and up the call chain the next I'm seeing is the "(let copy ...)" loop from object-unevict. The offending call seems to be hash-table-ref/default in the cond within that "copy" loop. So unless someone is found, who is competent enough to debug object-evict/object-unevict, I'm afraid I'm lost. At worst I'd recommend to simply remove the ability to use any Scheme object as file handle and simply require them to be integers. Then we could do away with the evict/unevict code. Any thought? Thanks /Jörg Am 10.03.2014 09:34, schrieb "Jörg F. Wittenberger": Am 09.03.2014 21:01, schrieb Evan Hanson: Hi Jörg, thanks for looking into this. Indeed, there's definitely more copying happening than really needs to. ___ 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
Hi again, Moritz Heidkamp writes: > I have a new version of this patch on my machine which applies cleanly > again (Felix already reviewed it). I'll post it here when I'm back at > it! find it attached! Moritz >From 4064075061189c7b743b69ebbacad82a089c5c34 Mon Sep 17 00:00:00 2001 From: felix Date: Thu, 19 Dec 2013 11:02:06 +0100 Subject: [PATCH] Added basic iOS support. --- Makefile.ios | 111 ++ README| 32 +++ distribution/manifest | 1 + tcp.scm | 33 --- 4 files changed, 171 insertions(+), 6 deletions(-) create mode 100644 Makefile.ios diff --git a/Makefile.ios b/Makefile.ios new file mode 100644 index 000..dff7875 --- /dev/null +++ b/Makefile.ios @@ -0,0 +1,111 @@ +# Makefile.ios - configuration for Apple iOS -*- Makefile -*- +# +# Copyright (c) 2013, The Chicken Team +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following +# conditions are met: +# +# Redistributions of source code must retain the above copyright notice, this list of conditions and the following +# disclaimer. +# Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following +# disclaimer in the documentation and/or other materials provided with the distribution. +# Neither the name of the author nor the names of its contributors may be used to endorse or promote +# products derived from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS +# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR +# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR +# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. + + +ifneq ($(CONFIG),) +include $(CONFIG) +endif + +SRCDIR = ./ + +# platform configuration + +# for simulator: ARCH ?= i386 +ARCH ?= armv7 +XCODE_PATH ?= /Applications/Xcode.app +XCODE_DEVELOPER ?= $(XCODE_PATH)/Contents/Developer +# for Xcode 4: XCODE_TOOLPATH ?= $(XCODE_DEVELOPER)/Toolchains/XCodeDefault.xctoolchain/usr/bin +XCODE_TOOLPATH ?= $(XCODE_DEVELOPER)/usr/bin +# for simulator: XCODE_SDK ?= $(XCODE_DEVELOPER)/Platforms/iPhoneSimulator.platform/Developer/SDKs/ipHoneSimulator7.0.sdk +XCODE_SDK ?= $(XCODE_DEVELOPER)/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk +STATICBUILD = 1 +HACKED_APPLY = + +# options + +# for Xcode 4: C_COMPILER ?= $(XCODE_DEVELOPER)/Platforms/iPhoneOS.platform/iPhoneOS.platform/Developer/usr/bin +C_COMPILER ?= $(XCODE_TOOLPATH)/gcc +LIBRARIAN ?= $(XCODE_DEVELOPER)/Platforms/iPhoneOS.platform/Developer/usr/bin/ar +C_COMPILER_OPTIONS ?= -no-cpp-precomp -fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -mno-thumb -isysroot $(XCODE_SDK) -arch $(ARCH) +ifdef DEBUGBUILD +C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused +else +ifdef OPTIMIZE_FOR_SPEED +C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer +else +C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer +endif +endif +LIBRARIAN_OPTIONS = scru +ASSEMBLER_OPTIONS = +LINKER_OPTIONS = -isysroot $(XCODE_SDK) -arch $(ARCH) + +# special files + +CHICKEN_CONFIG_H = chicken-config.h + +# select default and internal settings + +include $(SRCDIR)/defaults.make + +chicken-config.h: chicken-defaults.h + echo "/* GENERATED */" >$@ + echo "#define HAVE_DIRENT_H 1" >>$@ + echo "#define HAVE_INTTYPES_H 1" >>$@ + echo "#define HAVE_LIMITS_H 1" >>$@ + echo "#define HAVE_LONG_LONG 1" >>$@ + echo "#define HAVE_MEMMOVE 1" >>$@ + echo "#define HAVE_MEMORY_H 1" >>$@ + echo "#define HAVE_POSIX_POLL 1" >>$@ + echo "#define HAVE_SIGACTION 1" >>$@ + echo "#define HAVE_SIGSETJMP 1" >>$@ + echo "#define HAVE_SIGPROCMASK 1" >>$@ + echo "#define HAVE_STDINT_H 1" >>$@ + echo "#define HAVE_STDLIB_H 1" >>$@ + echo "#define HAVE_STRERROR 1" >>$@ + echo "#define HAVE_STRINGS_H 1" >>$@ + echo "#define HAVE_STRING_H 1" >>$@ + echo "#define HAVE_STRTOLL 1" >>$@ + echo "#define HAVE_STRTOQ 1" >>$@ + echo "#define HAVE_SYS_STAT_H 1" >>$@ + echo "#define HAVE_SYS_TYPES_H 1" >>$@ + echo "#define HAVE_UNISTD_H 1" >>$@ + echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ + echo "#define STDC_HEADERS 1" >>$@ + echo "#define HAVE_ALLOCA 1" >>$@ + echo "#define HAVE_ALLOCA_H 1" >>$@ + echo "#define HAVE_GRP_H 1" >>$@ + echo "#define HAVE_ERRNO
