Re: c99 support
> On 29 Jun 2018, at 17:35, Chris Vine wrote: > > On Fri, 29 Jun 2018 12:34:07 +0200 > Hans Åberg wrote: >>> If, say, uint8_t is available in stdint.h for C, it >>> will be available for C++. §21.4.1/2 of C++17 makes this even more >>> explicit: "The [cstdint] header defines all types and macros the >>> same as the C standard library header ". >> >> Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__. > > In C++17, references to "C" are to ISO/IEC 9899:2011. References to the > C standard library are to "the library described in Clause 7 of ISO/IEC > 9899:2011". In C++11 and C++14, the references are to ISO/IEC > 9899:1999. Good. > By default (if you don't use the -std=c++xx flag) g++-7 > compiles according to C++14. I am using C++17. And gcc7 defaults to C11, so there is an incompatibility with the default g++ C version it seems.
Re: guile 3 update, june 2018 edition
Greetings Andy! Andy Wingo wrote: > Hi, > > Just wanted to give an update on Guile 3 developments. Last note was > here: > > https://lists.gnu.org/archive/html/guile-devel/2018-04/msg4.html > > The news is that the VM has been completely converted over to call out > to the Guile runtime through an "intrinsics" vtable. For some > intrinsics, the compiler will emit specialized call-intrinsic opcodes. > (There's one of these opcodes for each intrinsic function type.) For > others that are a bit more specialized, like the intrinsic used in > call-with-prompt, the VM calls out directly to the intrinsic. Very exciting! However, master is not building for me. :( git clean -dxf; ./autogen.sh && ./configure && make -j5 gives me SNARF atomic.x SNARF backtrace.x SNARF boolean.x In file included from atomic.c:29:0: extensions.h:26:30: fatal error: libguile/libpath.h: No such file or directory #include "libguile/libpath.h" ^ compilation terminated. Makefile:3893: recipe for target 'atomic.x' failed make[2]: *** [atomic.x] Error 1 Maybe some dependency tuning is needed? So. Building without -j : make clean; make gives gives a segfault when generating the docs SNARF regex-posix.doc GEN guile-procedures.texi Uncaught exception: Backtrace: /bin/bash: line 1: 13428 Broken pipe cat alist.doc array-handle.doc array-map.doc arrays.doc async.doc atomic.doc backtrace.doc boolean.doc bitvectors.doc bytevectors.doc chars.doc control.doc continuations.doc debug.doc deprecated.doc deprecation.doc dynl.doc dynwind.doc eq.doc error.doc eval.doc evalext.doc expand.doc extensions.doc fdes-finalizers.doc feature.doc filesys.doc fluids.doc foreign.doc fports.doc gc-malloc.doc gc.doc gettext.doc generalized-arrays.doc generalized-vectors.doc goops.doc gsubr.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc list.doc load.doc macros.doc mallocs.doc memoize.doc modules.doc numbers.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc promises.doc r6rs-ports.doc random.doc rdelim.doc read.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc srfi-1.doc srfi-4.doc srfi-13.doc srfi-14.doc srfi-60.doc stackchk.doc stacks.doc stime.doc strings.doc strorder.doc strports.doc struct.doc symbols.doc syntax.doc threads.doc throw.doc trees.doc unicode.doc uniform.doc values.doc variable.doc vectors.doc version.doc vports.doc weak-set.doc weak-table.doc weak-vector.doc dynl.doc posix.doc net_db.doc socket.doc regex-posix.doc 13429 Segmentation fault | GUILE_AUTO_COMPILE=0 ../meta/build-env guild snarf-check-and-output-texi > guile-procedures.texi Makefile:3910: recipe for target 'guile-procedures.texi' failed This is $ git describe v2.2.2-504-gb5dcdf2e2 And gcc is $ gcc --version gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 On an up to date Debian 9.4 system: $ uname -a Linux debmetrix 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux -Dale
Re: c99 support
On Sat 23 Jun 2018 22:12, Andy Wingo writes:
> Is there anyone who compiles Guile with a compiler that does not support
> C99? If so, please give platform and compiler.
>
> I think my questions are limited to, in decreasing order of importance:
>
> * Is there any system that we target that doesn't have C99 stdint.h
> and stddef.h ?
>
> * Is there any system that we target that doesn't support C99 inline
> functions?
>
> * C99 mixed decls and statements?
>
> * C99 one-line comments (// foo) ?
>
> * C99 compound literals? ((struct x) { 1, 2 }) ?
>
> * stdbool.h
>
> I would like to use C99 inside Guile, and I want to eventually replace
> scm_t_uint8 with uint8_t.
Thanks all for the responses. It would seem that the first four
features of C99 are OK for all platforms that we target, with the
following caveats:
* We should avoid using C++ keywords (e.g. throw) in Guile API files.
* We might want to avoid mixed decls and statements in inline functions
in Guile API files.
We should probably avoid stdbool.h and compound literals, for C++
reasons.
In Guile 3.0 (master branch), the types "scm_t_uint8" and so on are now
deprecated. My recommendation is that all users switch to use
e.g. "uint8_t", "ptrdiff_t", etc from instead of the
scm_t_uint8, etc definitions that they are now using. The definitions
are compatible on all systems, AFAIU, and on GNU, scm_t_uint8 has long
been a simple typedef for uint8_t.
If you make the change while targetting current Guile (2.2), then you'll
won't have deprecation warnings when 3.0 comes out.
Cheers,
Andy
guile 3 update, june 2018 edition
Hi, Just wanted to give an update on Guile 3 developments. Last note was here: https://lists.gnu.org/archive/html/guile-devel/2018-04/msg4.html The news is that the VM has been completely converted over to call out to the Guile runtime through an "intrinsics" vtable. For some intrinsics, the compiler will emit specialized call-intrinsic opcodes. (There's one of these opcodes for each intrinsic function type.) For others that are a bit more specialized, like the intrinsic used in call-with-prompt, the VM calls out directly to the intrinsic. The upshot is that we're now ready to do JIT compilation. JIT-compiled code will use the intrinsics vtable to embed references to runtime routines. In some future, AOT-compiled code can keep the intrinsics vtable in a register, and call indirectly through that register. My current plan is that the frame overhead will still be two slots: the saved previous FP, and the saved return address. Right now the return address is always a bytecode address. In the future it will be bytecode or native code. Guile will keep a runtime routine marking regions of native code so it can know if it needs to if an RA is bytecode or native code, for debugging reasons; but in most operation, Guile won't need to know. The interpreter will tier up to JIT code through an adapter frame that will do impedance matching over virtual<->physical addresses. To tier down to the interpreter (e.g. when JIT code calls interpreted code), the JIT will simply return to the interpreter, which will pick up state from the virtual IP, SP, and FP saved in the VM state. We do walk the stack from Scheme sometimes, notably when making a backtrace. So, we'll make the runtime translate the JIT return addresses to virtual return addresses in the frame API. To Scheme, it will be as if all things were interpreted. This strategy relies on the JIT being a simple code generator, not an optimizer -- the state of the stack whether JIT or interpreted is the same. We can consider relaxing this in the future. My current problem is knowing when a callee has JIT code. Say you're in JITted function F which calls G. Can you directly jump to G's native code, or is G not compiled yet and you need to use the interpreter? I haven't solved this yet. "Known calls" that use call-label and similar can of course eagerly ensure their callees are JIT-compiled, at compilation time. Unknown calls are the problem. I don't know whether to consider reserving another word in scm_tc7_program objects for JIT code. I have avoided JIT overhead elsewhere and would like to do so here as well! For actual JIT code generation, I think my current plan is to import a copy of GNU lightning into Guile's source, using git-subtree merges. Lightning is fine for our purposes as we only need code generation, not optimization, and it supports lots of architectures: ARM, MIPS, PPC, SPARC, x86 / x86-64, IA64, HPPA, AArch64, S390, and Alpha. Lightning will be built statically into libguile. This has the advantage that we always know the version being used, and we are able to extend lightning without waiting for distros to pick up a new version. Already we will need to extend it to support atomic ops. Subtree merges should allow us to pick up upstream improvements without too much pain. This strategy also allows us to drop lightning in the future if that's the right thing. Basically from the user POV it should be transparent. The whole thing will be behind an --enable-jit / --disable-jit configure option. When it is working we can consider enabling shared lightning usage. Happy hacking, Andy
Re: c99 support
> On 29 Jun 2018, at 09:39, Andy Wingo wrote: > > It would seem that the first four > features of C99 are OK for all platforms that we target, with the > following caveats: > > * We should avoid using C++ keywords (e.g. throw) in Guile API files. > > * We might want to avoid mixed decls and statements in inline functions > in Guile API files. > > We should probably avoid stdbool.h and compound literals, for C++ > reasons. You might make a separate C++ header: It turned out too complicated for Bison to maintain the compile as C++ generated C parser. > In Guile 3.0 (master branch), the types "scm_t_uint8" and so on are now > deprecated. My recommendation is that all users switch to use > e.g. "uint8_t", "ptrdiff_t", etc from instead of the > scm_t_uint8, etc definitions that they are now using. The definitions > are compatible on all systems, AFAIU, and on GNU, scm_t_uint8 has long > been a simple typedef for uint8_t. For C++, these are only optional, cf. [1], as they require no padding. So an alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps leaving the API unchanged. 1. https://en.cppreference.com/w/cpp/types/integer
Re: c99 support
On Fri, 29 Jun 2018 12:34:07 +0200 Hans Åberg wrote: > > On 29 Jun 2018, at 12:10, Chris Vine wrote: > > > >> For C++, these are only optional, cf. [1], as they require no padding. So > >> an alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps > >> leaving the API unchanged. > >> > >> 1. https://en.cppreference.com/w/cpp/types/integer > > > > The fixed size integer types are optional in C99/11 also, depending on > > whether the platform provides a fixed size integer of the type in > > question without padding and (for negative integers) a two's complement > > representation. > > Yes, I saw that, too. It is important to ensure two's complement, too, which > the other types do not. > > > If, say, uint8_t is available in stdint.h for C, it > > will be available for C++. §21.4.1/2 of C++17 makes this even more > > explicit: "The [cstdint] header defines all types and macros the > > same as the C standard library header ". > > Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__. In C++17, references to "C" are to ISO/IEC 9899:2011. References to the C standard library are to "the library described in Clause 7 of ISO/IEC 9899:2011". In C++11 and C++14, the references are to ISO/IEC 9899:1999. By default (if you don't use the -std=c++xx flag) g++-7 compiles according to C++14.
Re: c99 support
> On 29 Jun 2018, at 12:10, Chris Vine wrote: > >> For C++, these are only optional, cf. [1], as they require no padding. So an >> alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps >> leaving the API unchanged. >> >> 1. https://en.cppreference.com/w/cpp/types/integer > > The fixed size integer types are optional in C99/11 also, depending on > whether the platform provides a fixed size integer of the type in > question without padding and (for negative integers) a two's complement > representation. Yes, I saw that, too. It is important to ensure two's complement, too, which the other types do not. > If, say, uint8_t is available in stdint.h for C, it > will be available for C++. §21.4.1/2 of C++17 makes this even more > explicit: "The [cstdint] header defines all types and macros the > same as the C standard library header ". Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__. > I imagine guile will not run on any platform that does not support 8 > and 32 bit fixed size integers. I would think all CPUs support those types nowadays, so it is rather theoretical.
Re: c99 support
On Fri, 29 Jun 2018 10:39:33 +0200 Hans Åberg wrote: > > On 29 Jun 2018, at 09:39, Andy Wingo wrote: > > > > It would seem that the first four > > features of C99 are OK for all platforms that we target, with the > > following caveats: > > > > * We should avoid using C++ keywords (e.g. throw) in Guile API files. > > > > * We might want to avoid mixed decls and statements in inline functions > > in Guile API files. > > > > We should probably avoid stdbool.h and compound literals, for C++ > > reasons. > > You might make a separate C++ header: It turned out too complicated for Bison > to maintain the compile as C++ generated C parser. > > > In Guile 3.0 (master branch), the types "scm_t_uint8" and so on are now > > deprecated. My recommendation is that all users switch to use > > e.g. "uint8_t", "ptrdiff_t", etc from instead of the > > scm_t_uint8, etc definitions that they are now using. The definitions > > are compatible on all systems, AFAIU, and on GNU, scm_t_uint8 has long > > been a simple typedef for uint8_t. > > For C++, these are only optional, cf. [1], as they require no padding. So an > alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps > leaving the API unchanged. > > 1. https://en.cppreference.com/w/cpp/types/integer The fixed size integer types are optional in C99/11 also, depending on whether the platform provides a fixed size integer of the type in question without padding and (for negative integers) a two's complement representation. If, say, uint8_t is available in stdint.h for C, it will be available for C++. §21.4.1/2 of C++17 makes this even more explicit: "The [cstdint] header defines all types and macros the same as the C standard library header ". I imagine guile will not run on any platform that does not support 8 and 32 bit fixed size integers.
crashes with Fibers
Hi,
I'm encountering a few crashes with Fibers that happen when I call
CALL-WITH-NEW-THREAD in a Fiber. TEST4 crashes every time. TEST5 never
outputs, but it doesn't crash every time.
TEST1 is exactly like TEST5 except that I replace CALL-WITH-NEW-THREAD
with SPAWN-FIBER.
Is it a mistake from me or a Guile bug? If it is a bug, do you know if
there are workarounds?
Thank you,
Clément
(use-modules (fibers channels)
(fibers))
;; good
(define (test1)
(run-fibers
(lambda ()
(spawn-fiber
(lambda ()
(let ((channel (make-channel)))
(spawn-fiber
(lambda ()
(put-message channel "hello world")))
(format #t "~a~%" (get-message channel))
#:drain? #t))
⊣ hello world
;; good
(define (test2)
(let ((channel (make-channel)))
(call-with-new-thread
(lambda ()
(put-message channel "hello world")))
(format #t "~a~%" (get-message channel
⊣ hello world
⇒ #t
;; good
(define (test3)
(run-fibers
(lambda ()
(let ((channel (make-channel)))
(call-with-new-thread
(lambda ()
(put-message channel "hello world")))
(format #t "~a~%" (get-message channel
#:drain? #t))
⊣ hello world
⇒ #t
;; bad
(define (test4)
(run-fibers
(lambda ()
(spawn-fiber
(lambda ()
(let ((channel (make-channel)))
(call-with-new-thread
(lambda ()
(put-message channel "hello world")))
#:drain? #t))
⊣ scheme@(guile-user)> In
/home/clement/.guix-profile/share/guile/site/2.2/fibers/internal.scm:
402:6 1 (suspend-current-fiber _)
In unknown file:
0 (scm-error misc-error #f "~A" ("Attempt to suspend fiber
within continuation barrier") #f)
ERROR: In procedure scm-error:
Attempt to suspend fiber within continuation barrier
;; bad
(define (test5)
(run-fibers
(lambda ()
(spawn-fiber
(lambda ()
(let ((channel (make-channel)))
(call-with-new-thread
(lambda ()
(put-message channel "hello world")))
(format #t "~a~%" (get-message channel))
#:drain? #t))
⊣ scheme@(guile-user)> In
/home/clement/.guix-profile/share/guile/site/2.2/fibers/operations.scm:
188:5 3 (perform-operation #< wrap-fn: #f try-fn:
# block-fn: #>)
In /home/clement/.guix-profile/share/guile/site/2.2/fibers/channels.scm:
88:26 2 (try-fn)
In /home/clement/.guix-profile/share/guile/site/2.2/fibers/internal.scm:
219:6 1 (schedule-fiber! _ _)
In unknown file:
0 (scm-error misc-error #f "~A" ("epoll instance is dead") #f)
ERROR: In procedure scm-error:
epoll instance is dead
