http://permalink.gmane.org/gmane.lisp.guile.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.lisp.guile.bugs/7180 <pre>Hi, I am trying to build a debian package from Debian's guile sources on a Dreamplug (ARMel/armv5tel arch) I am not sure what the following means but this is a 2-4 hour build process on this machine so any help would be appreciated make[6]: Nothing to be done for `test-import-order'. make[6]: Nothing to be done for `test-command-line-encoding'. make[6]: Nothing to be done for `test-asmobs'. make[6]: Nothing to be done for `test-ffi'. make[6]: `test-fast-slot-ref' is up to date. make[6]: Nothing to be done for `test-mb-regexp'. make[6]: `test-use-srfi' is up to date. make[6]: Nothing to be done for `test-extensions'. make[6]: Leaving directory `/media/files/src/guile-2.0-2.0.5+1/test-suite/standalone' make check-TESTS make[6]: Entering directory `/media/files/src/guile-2.0-2.0.5+1/test-suite/standalone' PASS: test-system-cmds PASS: test-bad-identifiers PASS: test-require-extension PASS: test-guile-snarf PASS: test-import-order PASS: test-command-line-encoding PASS: test-num2integral PASS: test-round PASS: </pre> Adam Baxter 2013-06-18T13:14:35 http://permalink.gmane.org/gmane.lisp.guile.bugs/7179 <pre>When using SA_RESTART, signal handlers are never executed, as in this example (checked on 2.0.9+): --8&lt;---------------cut here---------------start-------------&gt;8--- (sigaction SIGALRM (lambda (signum) (pk 'sig signum)) SA_RESTART) (alarm 3) (pk 'char (read-char)) --8&lt;---------------cut here---------------end---------------&gt;8--- Presumably this is because the read(2) syscall is automatically restarted, leaving no chance for the handler async to run. Ludo’. </pre> Ludovic Courtès 2013-06-17T13:54:45 http://permalink.gmane.org/gmane.lisp.guile.bugs/7178 <pre> For floats nothing would change anyway. Those are 4byte data types with 4byte alignment already. As for the larger types, you can still make them in any alignment with the take functions. Just the default would the optimized one when you add padding, and that's what it should be, since the scheme programmer doesn't care about the underlying memory layouts as much as the C programmer does. In normal guile uniform vector use you are completely oblivious to the underlying vector implementation, apart from the performance. In short: an array of floats is still an array of floats, and you can create them at any alignment, although cumbersomely. But the very point if creating arrays of native types is to better use the underlying hardware. And not taking advantage of alignment there unless you absolutely can't is negligent at best. You don't need a special annotation if the default alignment is the native alignment of the native type. If you create arrays of native types that is what you want in the</pre> Jan Schukat 2013-06-17T10:04:05 http://permalink.gmane.org/gmane.lisp.guile.bugs/7177 <pre>Jan Schukat &lt;shookie&lt; at &gt;email.de&gt; skribis: I think it would be wrong. An array of floats is an array of floats, regardless of its alignment. Well yeah, though you’d still need to come up with an annotation for that, and I’m not enthusiastic about changing the read syntax for that purpose. Now, I think the compiler should support a generic annotation mechanism, to allow users to specify various things (like ‘declare’ in some implementations.) That could be one possible use. Ludo’. </pre> Ludovic Courtès 2013-06-14T12:21:38 http://permalink.gmane.org/gmane.lisp.guile.bugs/7176 <pre> The more I think about it and hear what you have to say, the more I think alignment just needs to be tied to the type of the uniform array. Up to float and int 32 arrays nothing will change then. Double and int64 arrays get one word of padding on 32 bit machines to make them 8 byte aligned. And then introduce new type flags m128 and m256 for for simd types that are 16 or 32 byte bit aligned, possibly the complex arrays too. Since you can interpret uniform arrays as all types of uniform array this should solve all alignment problems where needed. The simd type arrays must be able to accept and recognize int and float immediates though, and you must be able to group them. That's not really much new syntax, and won't interfere with the old syntax. Also, now I lean more towards switching to 2.2 for myself and implement it on there, because as Ludovic said, the compiling will possibly preserve alignment there better. Regards Jan Schukat </pre> Jan Schukat 2013-06-14T08:32:20 http://permalink.gmane.org/gmane.lisp.guile.bugs/7175 <pre> I agree. The read syntax for vector-ish types in guile is already large enough. If alignment is important then use a procedural constructor and query. Alignment information not need to be printed with the default representation (read syntax), we dont also print the storage address, etc.. Regards </pre> Daniel Hartwig 2013-06-14T01:33:37 http://permalink.gmane.org/gmane.lisp.guile.bugs/7174 <pre> Douglas, did you run Boehm GC's "make check"? What version of GC is it? I recommend version 4.2d. Mark </pre> Mark H Weaver 2013-06-13T20:54:57 http://permalink.gmane.org/gmane.lisp.guile.bugs/7173 <pre>Hi, Thanks for sharing your thoughts on this! Jan Schukat &lt;shookie&lt; at &gt;email.de&gt; skribis: What about something like ‘make-aligned-bytevector’? This should be enough, since bytevectors can be accessed through the SRFI-4 API (info "(guile) Bytevectors as Uniform Arrays"). (And it can already be implemented in Scheme, as I showed previously.) I agree that we’d need some sort of annotation to specify the alignment of literals, but adding read syntax for that scares me somewhat. What do people think? On the compilation side, I think alignment will be more easily handled in 2.2 (current ‘master’), which uses ELF (think of GCC’s ‘alignment’ attribute.) None of this really seems doable in the 2.0 stable series. So for now you’d have to resort to one of the options discussed. WDYT? Thanks, Ludo’. </pre> Ludovic Courtès 2013-06-13T13:31:01 http://permalink.gmane.org/gmane.lisp.guile.bugs/7172 <pre>Hello again :) On 06/12/2013 10:37 PM, Andy Wingo wrote: Yes, 16 bytes. But more could be useful too. And as I have stated in my previous mail, the first element of the vector is guaranteed to be 4 byte aligned on 32 bit machines, because it starts directly after the 3 word header, which is allocated at 8 byte boundaries. And yes, I have tested this, but should be obvious from the code too. Don't really understand the danger here, isn't this allocated as a whole block and only collected as a whole block too? What am I missing? Having the arrays aligned according to their type by default could be a nice option, i.e. a word of padding for long and doubles on 32 bit machines, and then also introducing a new 16byte simd128 and 32 byte simd256 type id and their respective creation functions. Regards Jan Schukat </pre> Jan Schukat 2013-06-13T07:07:41 http://permalink.gmane.org/gmane.lisp.guile.bugs/7171 <pre>Thought a bit about it, and it would really be nice to have an aligned uniform vector API. ATM all are 8 byte aligned, so you probably would want also to be able to have at least 16 and 32 byte alignment (intel's AVX has 256bit registers that better work aligned). But even 64 and and more could be useful for cache line alignment, although that would require this to be a separate alignment, because the benefits of cache line alignment are kind of defeated if the header is in a different cache line. So I guess just one alignment, namely that of the first element is feasible without wasting whole cache lines. If you really need that you can still use the take_*vector functions, and it's pretty rare to do such things anyway. But being able to control the alignment of the first element allows you to properly use simd instructions on those vectors. You don't even really need any more space to store alignment information, since that can be directly inferred from the bytevector content pointer, althou</pre> Jan Schukat 2013-06-12T21:14:31 http://permalink.gmane.org/gmane.lisp.guile.bugs/7170 <pre> 16 bytes I guess? Guile's uniforms are 8-byte-aligned by default, as you probably know. Just wondering if there is a better default. This is somewhat dangerous, as you could lose the pointer to the start, and then the contents get collected. I guess this can be fixed in master, if you set the "holder" field on a bytevector to the actual memory that you allocate. Andy </pre> Andy Wingo 2013-06-12T20:37:40 http://permalink.gmane.org/gmane.lisp.guile.bugs/7169 <pre> The whole point of me doing this is so I can use lisp files to define aligned data (and using lisp as a flexible text data format that can be compiled is the primary reason I use guile). So either I make normal vectors aligned, or I define a whole new set of datatypes of aligned vectors with their own read syntax. The former I just did today, the latter would take me probably a quite a bit of time to do properly. So, I'm gonna keep using my compile time option for now, and probably write a module of aligned vectors at some point in the future when I have more of an understanding what exactly the requirements for something like this would be. Jan </pre> Jan Schukat 2013-06-12T15:32:35 http://permalink.gmane.org/gmane.lisp.guile.bugs/7168 <pre>severity 14599 wishlist thanks Hi! Jan Schukat &lt;shookie&lt; at &gt;email.de&gt; skribis: [...] I don’t think it should be a compile-time option, because it would be inflexible and inconvenient. Instead, I would suggest using the scm_take_ functions if allocating from C, as you noted. In Scheme, I came up with the following hack: --8&lt;---------------cut here---------------start-------------&gt;8--- (use-modules (system foreign) (rnrs bytevectors) (ice-9 match)) (define (memalign len alignment) (let* ((b (make-bytevector (+ len alignment))) (p (bytevector-&gt;pointer b)) (a (pointer-address p))) (match (modulo a alignment) (0 b) (padding (let ((p (make-pointer (+ a (- alignment padding))))) ;; XXX: Keep a weak reference to B or it can be collected ;; behind our back. (pointer-&gt;bytevector p len)))))) --8&lt;---------------cut here---------------end---------------&gt;8--- Not particularly elegant, but it does the job. ;-) Do you </pre> Ludovic Courtès 2013-06-12T14:59:01 http://permalink.gmane.org/gmane.lisp.guile.bugs/7167 <pre>Hello, If you want to access native uniform vectors from c, sometimes you really want guarantees about the alignment. Fortunately the the (byte)vector format and allocation makes that pretty easy to implement: just add a little padding between the header and the actual data. So for my own project, this is what I'm doing, and there shouldn't be much of a memory impact unless there are tons of small vectors used, which isn't very lispy anyway. This isn't necessarily true for vectors created from pre-existing buffers (the take_*vector functions), but there you have control over the pointer you pass, so you can make it true if needed. So if there is interest, maybe this could be integrated into the build system as a configuration like this: --- libguile/bytevectors.c 2013-04-11 02:16:30.000000000 +0200 +++ bytevectors.c 2013-06-12 14:45:16.000000000 +0200 &lt; at &gt;&lt; at &gt; -223,10 +223,18 &lt; at &gt;&lt; at &gt; c_len = len * (scm_i_array_element_type_sizes[element_type] / 8); +#ifdef SCM_VECTOR_ALIGN + contents</pre> Jan Schukat 2013-06-12T13:37:28 http://permalink.gmane.org/gmane.lisp.guile.bugs/7166 <pre>Hi Eric, "Eric Sheibley" &lt;e_sheibley&lt; at &gt;verizon.net&gt; writes: Apparently you're not successfully linking to libffi, which should contain those ffi_* symbols. What FFI-related options or environment variables did you pass to ./configure? I'd like to see the output of "grep -i libffi config.log". It also appears that Guile was configured with thread support, but that your libgc was built without thread support. If you don't need thread support, then I suggest passing "--without-threads" to ./configure, otherwise you'll need to rebuild libgc (preferably version 7.2d) with thread support. Regards, Mark </pre> Mark H Weaver 2013-06-10T20:48:19 http://permalink.gmane.org/gmane.lisp.guile.bugs/7165 <pre>Ludo, I figured it out but now I am getting another error when running 'make all' CCLD guile Undefined symbolfirst referenced in file ffi_closure_alloc./.libs/libguile-2.0.so ffi_type_pointer ffi_prep_closure_loc ffi_type_uint8 ffi_type_sint8 ffi_type_float GC_unregister_my_thread ffi_type_uint32 ffi_type_uint16 ffi_type_uint64 ffi_type_sint32 ffi_type_sint16 ffi_type_sint64 ffi_type_void ffi_type_double GC_register_my_thread ffi_call ffi_closure_free ffi_prop_cif GC_pthread_create GC_pthread_detach ld:fatal:symbol reference errors. No output written to .lib/guile collect2: ld returned 1 exit status I get this error when using either the Solaris 10 built in gcc version 3.4.3 or Solaris Studio version 12.3 as the compiler. Eric -----Original Message----- From: Ludovic "Courtès" [mailto:ludo&lt; at &gt;gnu.org] Sent: Wednesday, June 05, 2013 17:27 To: e_sheibley&lt; at &gt;verizon.net Cc: 14550&lt; at &gt;debbugs.gnu.org Subject: Re: bug#14550: libltdl not found during configure of Guile 2.0.9 Eric, (Please keep 14550&lt; at &gt;debbugs.gnu.o</pre> Eric Sheibley 2013-06-10T19:50:49 http://permalink.gmane.org/gmane.lisp.guile.bugs/7164 <pre>Will do. Thanks for your time, and sorry about my mistake. -Shane On Jun 7, 2013, at 5:16 PM, Mark H Weaver &lt;mhw&lt; at &gt;netris.org&gt; wrote: </pre> Shane Celis 2013-06-10T16:06:01 http://permalink.gmane.org/gmane.lisp.guile.bugs/7163 <pre> In the future, please send the relevant information as attachments, so that it's recorded in our bug tracking system. For posterity, here it is: --8&lt;---------------cut here---------------start-------------&gt;8--- /* This file demonstrates a bug with C goto labels and Guile. $ gcc `pkg-config guile-2.0 --cflags --libs` goto_label_bug.c -o goto_label_bug goto_label_bug.c: In function 'main': goto_label_bug.c:10: error: expected expression before 'SCM' $ gcc `pkg-config guile-2.0 --cflags --libs` goto_label_bug.c -o goto_label_bug -D INSERT_NOOP $ # No problem. Shane Celis */ #include &lt;libguile.h&gt; int main(int argc, char *argv[]) { scm_init_guile(); goto end; end: #ifdef INSERT_NOOP ; /* No error with dummy statement. */ #endif SCM dummy = SCM_BOOL_T; /* Causes error. */ return 0; } --8&lt;---------------cut here---------------end---------------&gt;8--- This is unrelated to Guile. The same problem happens with GCC 4.7 if you make the following substitutions:</pre> Mark H Weaver 2013-06-07T21:16:32 http://permalink.gmane.org/gmane.lisp.guile.bugs/7162 <pre>If a goto label is followed by an SCM variable declaration, a compilation error will result. I've written up this piece of code that demonstrates the behavior and how to work around it, available here: https://gist.github.com/shanecelis/5728982 -Shane </pre> Shane Celis 2013-06-07T12:50:38 http://permalink.gmane.org/gmane.lisp.guile.bugs/7161 <pre></pre> e_sheibley< at >verizon.net 2013-06-05T13:13:27 http://permalink.gmane.org/gmane.lisp.guile.bugs/7160 <pre>Eric, (Please keep 14550&lt; at &gt;debbugs.gnu.org Cc'd.) e_sheibley&lt; at &gt;verizon.net skribis: I know. Yet, ‘configure’ creates a ‘config.log’ file with additional details, as I explained. Can you please check its contents according to the recommendations I gave? Thanks in advance, Ludo’. </pre> Ludovic Courtès 2013-06-05T21:27:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.lisp.guile.bugs