Shawn Rutledge | 1 Aug 08:15 2008
Picon

Re: return a pair of ints from a C function?

On Thu, Jul 31, 2008 at 3:59 PM, felix winkelmann <bunny351 <at> gmail.com> wrote:
>>> either have to use `foreign-primitive`(to create a CPS function), or
>>
>> Why don't you prefer that approach?
>
> Well, the pass-the-box approach appeared simpler, but foreign-primitive
> is probably the cleaner approach and doesn't require you to create
> a wrapper function.

Thanks for your help.

This works:

(define g2d_glyphs_baseline (foreign-primitive scheme-object
((g2d-glyph-vector glyphs))
        "C_word* a = C_alloc(C_SIZEOF_PAIR);
	return(C_pair (&a, C_fix(10), C_fix(256)));" ))

but is there a way to do it in a C source file rather than having to
write C inside quotes?
Shawn Rutledge | 1 Aug 08:18 2008
Picon

Re: return a pair of ints from a C function?

On Thu, Jul 31, 2008 at 12:46 AM, Ivan Raikov <raikov <at> oist.jp> wrote:
>
> To return fixnums, you can do:
>
> C_word g2d_glyphs_baseline(struct G2dGlyphs* glyphs)
> {
>        C_word* a = C_alloc(C_SIZEOF_PAIR);
>        C_return(C_pair (&a, C_fix(10), C_fix(256)));
> }

Thanks.  But it appears there is the problem Felix is referring to,
that it's only on the stack (although I thought that was OK for it to
be on the stack):  when I ran this C function from a Scheme wrapper I
got

(10 . #<procedure>)
Aleksej Saushev | 1 Aug 20:42 2008
Picon

Last two snapshots (3.3.5 and 3.3.6) are broken

  Hello!

Last two snapshots are broken, the build with host PCRE fails,
currently I've patched it (see the patch below), but I want to
raise the issue once again.

Please, don't build against bundled pcre, at least for BSD's,
the policy on all of them (known to me) is to build against
common libraries, not package-internal ones.

It would be nice, if bundled pcre was dropped at all, this will
ease maintanance and testing, and prevent you from making such
stupid mistakes.

Appendices.

Fix PCRE references.

--- rules.make.orig	2008-07-30 08:00:05.000000000 +0400
+++ rules.make	2008-08-01 17:40:49.000000000 +0400
 <at>  <at>  -135,7 +135,11  <at>  <at> 
 	$(C_COMPILER) $(C_COMPILER_OPTIONS) $(C_COMPILER_PTABLES_OPTIONS) $(INCLUDES) \
 	  $(C_COMPILER_COMPILE_OPTION) $(C_COMPILER_OPTIMIZATION_OPTIONS)
$(C_COMPILER_SHARED_OPTIONS) \
 	  $(C_COMPILER_BUILD_RUNTIME_OPTIONS) $< $(C_COMPILER_OUTPUT)
+ifeq ($(USE_HOST_PCRE),)
 regex$(O): regex.c chicken.h $(CHICKEN_CONFIG_H) $(PCRE_DIR)/pcre.h
+else
+regex$(O): regex.c chicken.h $(CHICKEN_CONFIG_H)
+endif
(Continue reading)

Ivan Raikov | 2 Aug 03:24 2008
Picon

Re: Last two snapshots (3.3.5 and 3.3.6) are broken


Hi Aleksej,

   Thanks for the patch. I have removed the pcre.h dependencies from
the regex targets altogether, as pcre.h is supposed to be immutable,
anyway. trunk now seems to build fine with or without USE_HOST_PCRE,
but give it a try and let me know if it works for you. The next
development release, 3.3.7, will include those changes, and will be
available in about 6 hours or so.

   Your point about bundled pcre is well-taken, and in fact the Debian
package is also built with USE_HOST_PCRE=1 for precisely that
reason. Unfortunately, some older Debian distributions still use pcre
6.x, whose header file is missing some definitions used by the regex
unit in Chicken, so it is not always possible to use host pcre. I am
actually in favor of dropping the use of pcre altogether, and adopting
Alex Shinn's irregex library in the Chicken core, because
"Perl-compatible" regular expressions are full of godawful hacks, and
because the pcre library itself is an overflow vulnerability waiting
to happen [1]. That is usually the case with large, complex C
libraries, and I think it is a bad idea in general to include
third-party C code in core Chicken.

   -Ivan

[1] http://www.usenix.org/event/woot08/tech/full_papers/drewry/drewry_html/

Aleksej Saushev <asau <at> inbox.ru> writes:

> Hello!
(Continue reading)

felix winkelmann | 2 Aug 12:11 2008
Picon

Re: Last two snapshots (3.3.5 and 3.3.6) are broken

On Sat, Aug 2, 2008 at 3:24 AM, Ivan Raikov <raikov <at> oist.jp> wrote:
>
>   Your point about bundled pcre is well-taken, and in fact the Debian
> package is also built with USE_HOST_PCRE=1 for precisely that
> reason. Unfortunately, some older Debian distributions still use pcre
> 6.x, whose header file is missing some definitions used by the regex
> unit in Chicken, so it is not always possible to use host pcre. I am
> actually in favor of dropping the use of pcre altogether, and adopting
> Alex Shinn's irregex library in the Chicken core, because
> "Perl-compatible" regular expressions are full of godawful hacks, and
> because the pcre library itself is an overflow vulnerability waiting
> to happen [1]. That is usually the case with large, complex C
> libraries, and I think it is a bad idea in general to include
> third-party C code in core Chicken.
>

Generally I'm of the opinion not to use installed libraries to avoid
versioning problems. This is an endless source of trouble, as
todays UNIX systems (especially Linux) are a patchwork of libraries and it is
practically impossible to make any sort of assumption about what is
installed and whether it is compatible to our expectations. Now I do
see that in a well-maintained system that uses whatever package
system consistently (and provided that the installation is clean and
that the user doesn't upgrade like mad, as is practice on Gentoo
systems for example. Personally I do not upgrade an installed
system unless there is no other choice, but that's just how I
see this matter).

I agree that this big pile of foreign code in the souce tree stands
somewhat out and doesn't fit in too well. Actually, using irregex
(Continue reading)

felix winkelmann | 2 Aug 12:20 2008
Picon

Re: return a pair of ints from a C function?

On Fri, Aug 1, 2008 at 8:15 AM, Shawn Rutledge
<shawn.t.rutledge <at> gmail.com> wrote:
>
> This works:
>
> (define g2d_glyphs_baseline (foreign-primitive scheme-object
> ((g2d-glyph-vector glyphs))
>        "C_word* a = C_alloc(C_SIZEOF_PAIR);
>        return(C_pair (&a, C_fix(10), C_fix(256)));" ))
>
> but is there a way to do it in a C source file rather than having to
> write C inside quotes?
>

You can put a C function that looks like this into a separate
file and access it with ##core#primitive:

/* x.c */

#include "chicken.h"

C_word g2d_glyphs_baseline(C_word c, C_word self, C_word k, C_word glyphs)
{
  C_word *a = C_alloc(C_SIZEOF_PAIR);
  C_kontinue(k, C_pair(&a, C_fix(10), C_fix(256)));
}

/* y.scm */

#>
(Continue reading)

Peter Bex | 2 Aug 15:37 2008
Picon
Picon

Re: Last two snapshots (3.3.5 and 3.3.6) are broken

On Sat, Aug 02, 2008 at 12:11:08PM +0200, felix winkelmann wrote:
> I agree that this big pile of foreign code in the souce tree stands
> somewhat out and doesn't fit in too well. Actually, using irregex
> is really an option, but both performance and stability has to
> be evaluated thoroughly before committing to such a decision.

My 2 cents:
Why not make irregex part of core and create a PCRE egg?  That gives us
the best of both worlds, IMHO.

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-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Vincent Manis | 2 Aug 17:08 2008
Picon

Re: Last two snapshots (3.3.5 and 3.3.6) are broken

On 2008-Aug-2, at 06:37, Peter Bex wrote:
> Why not make irregex part of core and create a PCRE egg?  That gives  
> us
> the best of both worlds, IMHO.
+1 if irregex meets Felix's criteria of performance and reliability. 
Shawn Rutledge | 3 Aug 21:25 2008
Picon

Re: return a pair of ints from a C function?

On Sat, Aug 2, 2008 at 3:20 AM, felix winkelmann <bunny351 <at> gmail.com> wrote:
> You can put a C function that looks like this into a separate
> file and access it with ##core#primitive:

Thanks!
Jörg F. Wittenberger | 4 Aug 21:28 2008
Picon

Segfault - a hard one

Hi all,

Please find attached a self contained program, which is supposed to run
a useless thread for 3 seconds, kill it (logging a notice about an
exception being caught), create some garbage (logging a notice before
and afterwards) and exit properly.

To compile:
$ csc -o ttm ttm.scm

Here's the output on my machine:

$ ./ttm 
test
Load error in (define aa (with-timeout 3 (lambda () (do () (#f)
#t)))):(timeout) in (define aa (with-timeout 3 (lambda () (do () (#f)
#t))))
let's do some garbage
Segmentation fault
$ ./ttm 
test
Load error in (define aa (with-timeout 3 (lambda () (do () (#f)
#t)))):(timeout) in (define aa (with-timeout 3 (lambda () (do () (#f)
#t))))
let's do some garbage

out of memory - heap full while resizing - execution terminated

...more...
ttm.scm: 66   number->string
(Continue reading)


Gmane