Re: Build failures - compiling TeXmacs under guile 2.0.5
Hello! On 05/29/12 at 03:54pm, Ludovic Courtès wrote: > Hi! > > Jan Synacek skribis: > > > Hm, this is weird. So TeXmacs seems to bundle the same eval.scm as guile has > > (among others)? > > You mean TeXmacs ships a file called ice-9/eval.scm? If that is the > case, we’re in trouble. It doesn't, sorry for the confusion. My files got all mixed up somehow. > > > I tried to copy all the .go files from installation to > > /usr/share/guile/2.0 and remove those in /usr/lib64/guile/2.0/ccache, > > but that seems to have done nothing. > > Running “make install” in Guile installs everything in its right place, > with the right time stamp. I recompiled guile and the problem with compiling .go files is gone. However, TeXmacs still doesn't work and I'm not sure, if it's caused by the patch, or there is something else I'm overlooking again:) Texmacs complains when started: Backtrace: In unknown file: ?: 7 [boot-closure #t # ...] ?: 6 [catch-closure] ?: 5 [boot-closure #t # #] ?: 4 [catch-closure] ?: 3 [boot-closure #t # #] ?: 2 [catch-closure] ?: 1 [primitive-eval (if (os-mingw?) (load "kernel/boot/boot.scm") ...)] ?: 0 [primitive-load "/usr/share/TeXmacs/progs/xxx"] ERROR: In procedure primitive-load: ERROR: In procedure open-file: No such file or directory: "/usr/share/TeXmacs/progs/xxx" The 'xxx' in the path probably suggests that something went wrong, but I wasn't able to really track down the cause. > > Thanks, > Ludo’. Thanks, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat
Re: Build failures - compiling TeXmacs under guile 2.0.5
Hi, Jan Synacek skribis: > Texmacs complains when started: > > Backtrace: > In unknown file: >?: 7 [boot-closure #t # ...] >?: 6 [catch-closure] >?: 5 [boot-closure #t # #] >?: 4 [catch-closure] >?: 3 [boot-closure #t # #] >?: 2 [catch-closure] >?: 1 [primitive-eval (if (os-mingw?) (load "kernel/boot/boot.scm") ...)] >?: 0 [primitive-load "/usr/share/TeXmacs/progs/xxx"] > > ERROR: In procedure primitive-load: > ERROR: In procedure open-file: No such file or directory: > "/usr/share/TeXmacs/progs/xxx" > > > The 'xxx' in the path probably suggests that something went wrong, but I > wasn't > able to really track down the cause. I think you’d need to find the TeXmacs code snippet that’s being evaluated here. Ludo’.
%default-port-conversion-strategy and string ports
Hello! Commit b22e94db7c91d7661204e33f3bc2bfead002c9b7 adds ‘%default-port-conversion-strategy’, a natural friend of ‘%default-port-encoding’. First, I’m wondering whether ‘port’ should be part of the name, given that it’s also referred to by ‘scm_stringn’ & co. It’s good to have it in the name, for the symmetry with ‘%default-port-encoding’, but it’s not accurate. Second, in commit 9f6e3f5a997f484548bd03e7e7573c38a95c8d09, I changed string ports to honor it, like other port types, instead of forcing 'error. This seems like the right thing to me, for the sake of consistency (in fact, I’d consider the previous behavior as a bug), but it’s an observable change. WDYT? Thanks, Ludo’.
Re: %default-port-conversion-strategy and string ports
>Second, in commit 9f6e3f5a997f484548bd03e7e7573c38a95c8d09, I changed >string ports to honor it, like other port types, instead of forcing >'error. This seems like the right thing to me, for the sake of >consistency (in fact, I’d consider the previous behavior as a bug), but >it’s an observable change. Sounds fair. The 'error behavior for was once coupled with UTF-8, making the error mostly moot at the time, but, if string ports are honoring encoding they should probably honor the conversion strategy as well. -Mike
Re: assembler in scheme
On Sat, May 26, 2012 at 10:58 PM, Nala Ginrut wrote: > Well, speaking this. I have a question that, is there any convenient > way to add multi-backend in Guile? It depends on what you mean by that. You can add as many low-level languages as you like, including a GCC interface, machine code, and JVM bytecode. The compiler framework doesn't know the difference between frontends and backends (I think) - it just compiles from one language to another, using the compilers it knows about. When you're actually running Guile, only one of those languages can be executed, and it's the one corresponding to the actual virtual machine running Guile. But you could use the framework to statically compile JVM bytecode just fine, I think. It would be very cool to be able to run Guile on the JVM. I think it would really show the advantages of the compilation framework, because the Guile VM and JVM implementations would use the same intermediate language, with the same optimizations. However, I think that would be a lot of work. Noah
Re: %default-port-conversion-strategy and string ports
l...@gnu.org (Ludovic Courtès) writes: > Hello! > > Commit b22e94db7c91d7661204e33f3bc2bfead002c9b7 adds > ‘%default-port-conversion-strategy’, a natural friend of > ‘%default-port-encoding’. > > First, I’m wondering whether ‘port’ should be part of the name, given > that it’s also referred to by ‘scm_stringn’ & co. It’s good to have it > in the name, for the symmetry with ‘%default-port-encoding’, but it’s > not accurate. > > Second, in commit 9f6e3f5a997f484548bd03e7e7573c38a95c8d09, I changed > string ports to honor it, like other port types, instead of forcing > 'error. This seems like the right thing to me, for the sake of > consistency (in fact, I’d consider the previous behavior as a bug), but > it’s an observable change. > > WDYT? Shouldn't strings be in "internal encoding" anyway? The whole point of a string is to be an array of characters. Not an array of arbitrarily encoded bytes. -- David Kastrup
