<biblio>Pelescours: damo22: I was updating my workstation so could not connect to irc for a while. Let me know if you need any info about libacpica <damo22>i lost your latest patch because i switched my mail provider <biblio>damo22: I did not get any email. Just rechecked. I can send you the last patch again. <damo22>i sent an email to your member.fsf.org email <damo22>if you didnt get it, that could mean something is wrong with my mail configuration <biblio>damo22: just got your mail. thanks. <biblio>damo22: I sent patch with subject '[PATCH] PCI link query added' :) <damo22>will review and merge into my branch later <damo22>no wonder i was having trouble with acpi, i booted qemu without -smp 2 <damo22>hmm: #2 0x08054ab0 in acpi_tb_scan_memory_for_rsdp ( <damo22> start_address=0x1005c00 <error: Cannot access memory at address 0x1005c00>, length=1024) <damo22> at ../../libacpica/tbxfroot.c:243 <damo22>Pellescours: ive pushed something further to acpica-nothread branch, but it throws the above error <damo22>my branch no longer works on the commit i had it working before ***Mete-- is now known as Mete-
<curiosa>one thing that I understood looking at mig, is that while it claims to be language independent (Draves et al 1989) it has import declarations that wouldn't make any sense in any language that is not a C derivative, correct? <curiosa>next thing I will try to understand is why it had to be that way <curiosa>also gnumig is not exactly following that specification, but fine one could guess they really had to publish or perish ***Mete-- is now known as Mete-
<curiosa>my understanding is that if mig had to translate C types to the mach semantics, it would't have been an easy piece of software to port <curiosa>by doing what they did, they put a part of the burden of porting on the API programmer