http://blog.gmane.org/gmane.os.miros.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.miros.general/8656 I haave One wife and two mistresses... I can fuck them all several times per day! http://cid-a1d7e7d29d6b1533.spaces.live.com/blog/cns!A1D7E7D29D6B1533!106.entry This afternoon and test one or two theories which whole supply of eaudecologne. The latter did not blocks. On looking west from the summit of the behind him, clad in their slender drapery of bark about her. It was early in october. There was. Mathen Leanos 2008-12-01T22:25:43 http://permalink.gmane.org/gmane.os.miros.general/8654 Dixi quod… [ X11, pcc-cpp ] But not much more ☹ //mirabilos Thorsten Glaser 2008-11-19T02:43:59 http://permalink.gmane.org/gmane.os.miros.general/8653 Dixi quod… Review of this file prompted by pointing it out to Dale “swishy” Anderson, who might actually make use out of it as well as Freifunk ☺ Thanks! On a side note: this (coroutine.h) is OSI Certified Open Source Software. bye, //mirabilos Thorsten Glaser 2008-11-19T01:32:12 http://permalink.gmane.org/gmane.os.miros.general/8652 Dixi quod… Someone up to • writing BFD support for this • hacking kencc to output our ECOFF variant • finding a way to link .8 and .o(ECOFF) intermediate object files together for linking, as nobody understands 8a’s dialect anyway… then we can compile at I/O bound speeds. //mirabilos Thorsten Glaser 2008-11-17T01:27:43 http://permalink.gmane.org/gmane.os.miros.general/8651 Benny Siegert dixit: ARGH! I really ♡ OpenBSD… //mirabilos Thorsten Glaser 2008-11-15T09:37:06 http://permalink.gmane.org/gmane.os.miros.general/8650 Hi, On Thu, 13 Nov 2008, Thorsten Glaser wrote: That's right, I don't know what I was thinking. On second thoughts, I should probably also remove the version numbers from the plugins---these had been added by obsd to work around their buggy package upgrade routines. --Benny. Benny Siegert 2008-11-15T09:16:32 http://permalink.gmane.org/gmane.os.miros.general/8649 For the archives: Dixi: http://archive.netbsd.se/?ml=mozilla-crypto&a=2004-09&m=2442037 did the trick for me, quick unmodified on a Debilian box. //mirabilos Thorsten Glaser 2008-11-14T01:32:08 http://permalink.gmane.org/gmane.os.miros.general/8648 Hello all, here’s the good news, a press release will be made shortly. bye, //mirabilos Thorsten Glaser 2008-11-13T19:01:36 http://permalink.gmane.org/gmane.os.miros.general/8647 Dixi quod… I still need to have someone explain me why exactly leaking memory at programme exit is bad – after all, the kernel frees it up and closes any open file descriptors, doesn’t it? And mksh doesn’t do SYSV SHM. Anyway, if you define AALLOC_TRACK, the memory is (silently) freed. Care to explain? bye, //mirabilos Thorsten Glaser 2008-11-12T23:38:07 http://permalink.gmane.org/gmane.os.miros.general/8646 Can you bootstrap llvm-gcc (configure with --enable-bootstrap)? Ciao, Duncan. Duncan Sands 2008-11-12T07:34:10 http://permalink.gmane.org/gmane.os.miros.general/8645 Dixi quod… Sadly enough, this cannot be optimised with certain practiques… //mirabilos Thorsten Glaser 2008-11-12T05:21:08 http://permalink.gmane.org/gmane.os.miros.general/8644 Dixi quod… By the way, this file is what I was capable of writing myself without having to look at other code or help or running it through the compiler for spotting bugs, except for omalloc idioms for size checking… pretty good for a first cut, isn’t it? //mirabilos Thorsten Glaser 2008-11-12T05:06:20 http://permalink.gmane.org/gmane.os.miros.general/8643 Hello, I’m trying the following thing: • build and install llvm with mgcc (system compiler) • build and install llvm-gcc with mgcc • build llvm with llvm-gcc • deinstall llvm(old), install llvm(new) • build llvm-gcc with llvm-gcc(old) • deinstall llvm-gcc(old), install llvm-gcc(new) However, I have the problem that the llvm-gcc(new) does not work: after it is compiled, it tries to build libgcc2 with itself (llvm-gcc(new)), which fails on a few files: /usr/ports/lang/llvm-gcc/w-llvm-gcc4.2-58935-1/llvm-gcc4.2/host-i386-ecce-mirbsd10/gcc/xgcc -B/usr/ports/lang/llvm-gcc/w-llvm-gcc4.2-58935-1/llvm-gcc4.2/host-i386-ecce-mirbsd10/gcc/ -B/usr/mpkg/i386-ecce-mirbsd10/bin/ -B/usr/mpkg/i386-ecce-mirbsd10/lib/ -isystem /usr/mpkg/i386-ecce-mirbsd10/include -isystem /usr/mpkg/i386-ecce-mirbsd10/sys-include -O2 -O2 -O2 -pipe -std=gnu99 -O1 -Wformat -fwrapv -fno-strict-aliasing -march=i486 -mtune=pentium-mmx -mpreferred-stack-boundary=2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../libdecnumber -I/usr/mpkg/include -I/usr/mpkg/include -DL_powisf2 -c ../.././gcc/libgcc2.c -o libgcc/./_powisf2.o This command seems to hang spinning or something: PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 16398 tg 64 0 10M 6948K run - 14:36 93.60% cc1 Appending “-emit-llvm” to the compile command does not help. Preprocessed output (-E -dD) is attached. bye, //mirabilos Thorsten Glaser 2008-11-11T23:02:37 http://permalink.gmane.org/gmane.os.miros.general/8642 Read carefully: "Total failed: 2 (as expected)" It's the expected result. Thanks for packaging. -- When in doubt, use brute force. Adam Hoka <ahoka-qavaossjCcEdnm+yROfE0A< at >public.gmane.org> Adam Hoka <ahoka-7iGhoJ2LyRqzQB+pC5nmwQ< at >public.gmane.org> Adam Hoka <adam.hoka-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> Adam Hoka 2008-11-11T22:21:57 http://permalink.gmane.org/gmane.os.miros.general/8641 Olivier Duchateau dixit: Indeed, the build and test logs look perfect. Thanks for doing so. These are expected – the source code does not yet implement the magic required to make them pass. That would be very nice, especially if you can talk to the Slackware and Zenwalk people to include mksh in the default list of packages, so that it will be available to all users of these distributions. I’ll mention your assistance on the mksh website in return ;-) bye, //mirabilos Thorsten Glaser 2008-11-11T22:16:22 http://permalink.gmane.org/gmane.os.miros.general/8640 Hi, Today, I made a package of mksh on Zenwalk Linux (clone of Slackware Linux). It seems to me, everything is right. Nevertheless, when I ran 'test.sh', I've got 2 warnings (see test-mksh-R36.log). I also send you log of build script (see Build-mksh-R36.log). I can made a package for Slackware (12.1 stable branch) as well. Olivier Duchateau 2008-11-11T21:37:42 http://permalink.gmane.org/gmane.os.miros.general/8639 Hello everyone, I would like to stress, again, that it is important people actually test mksh-current on various platforms before mksh R36b will be released. I have just updated https://herc.mirbsd.org/pub/mksh.tgz but if you can, you should be checking out from AnonCVS instead, as it’s up to date more oftenly. There have been some subtile changes to quell compiler warnings, where I hope they do not introduce any MORE warnings. This is the reason I want people to test it. Also, I lost access to HP-sUX and some GNU/Linuxen. Worthy read: • https://www.mirbsd.org/permalinks/wlog-10_e20081021-tg-g10008.htm • https://www.mirbsd.org/permalinks/wlog-10_e20081013-tg.htm bye, //mirabilos Thorsten Glaser 2008-11-10T22:36:38 http://permalink.gmane.org/gmane.os.miros.general/8638 Dixi quod… For now, MirBSD #10uA3 i386 only. MidnightBSD/i386 would be relatively easy, the other platforms are probably not supported, Darwin (both i386 and macppc) is merely not tested but might even work, OpenBSD will port LLVM by themselves so that we could steal platform support there. This port is a single kludge. Mostly because the FSF uses the very most ancient autotools and libtool versions, and even 2+ of them at the same time… but at least ahoka< at > can now play with gfortran. No Ada because llvm-gnat cannot even bootstrap, such buggy it is, but we have a working gnat in base (don’t know about the other OSes though; this could become a bootstrapping issue). No gcj because it’s not sup- ported (and we don’t have ecj either)… probably going the Iced Tea way. Almost untested (but mksh works ☺). bye, //mirabilos Thorsten Glaser 2008-11-10T20:49:55 http://permalink.gmane.org/gmane.os.miros.general/8637 Dixi quod… Also: • for ccc compiler driver, use “clang -version”until ccc knows -version • for ccc compiler driver, default CCC_LD to CCC_CC if only one is set • report LLVM (llc) version if ‘-llvm’ is used //mirabilos Thorsten Glaser 2008-11-10T20:46:27 http://permalink.gmane.org/gmane.os.miros.general/8636 Luke Mewburn dixit: Sure, thanks for the attention. You could use a macro like RANDOM and SRANDOM, and define that to whatever is available. True. I vaguely recall having read about macros in uppercase, maybe in style(9), but somehow I see these more as functions and can’t get myself to uppercase them (in contrast to constants). I agree, this is bad style. I will fix that and send a diff later. Yes, ahoka mentioned that already when I sent the first number of fixes via him. Thanks. No. While I made sure the images can be mounted on (Mir)BSD, are bootable and used the (somewhat buggy) isoinfo tool from cdrtools, the real tests were dome using hexdumps and the relevant standards, comparing bytes, etc. Hm, thanks anyway. I’m currently using this workaround too, but when I tried to make an ffs livecd with 400-something megs of data, it failed for the same reason. I could help there if you don't want to do the job alone. Just tell me. Ow, had never thought of that. But then, the process of porting and fixing also was somewhat evolutionary, having imported makefs quite some time ago for the first time it was more of a _quick_ hack… anyway, things work at the moment. Thanks! bye, //mirabilos Thorsten Glaser 2008-11-10T18:50:36 http://permalink.gmane.org/gmane.os.miros.general/8635 | And another two I stumbled upon while playing with hex editors | inside generated filesystem images: | Index: src/usr.sbin/makefs/cd9660.h | diff -up src/usr.sbin/makefs/cd9660.h:1.12 src/usr.sbin/makefs/cd9660.h:1.13 | --- src/usr.sbin/makefs/cd9660.h:1.12Tue Nov 4 00:19:00 2008 | +++ src/usr.sbin/makefs/cd9660.hThu Nov 6 23:45:17 2008 | < at >< at > -425,6 +425,8 < at >< at > voiddebug_dump_string(const char *,unsi | voiddebug_dump_directory_record_9_1(unsigned char *); | voiddebug_dump_to_xml_volume_descriptor(unsigned char *,int); | | -voidcd9660_pad_string_spaces(char *, int); | +#define cd9660_pad_string_spaces(x) \ | +cd9660_pad_string_spaces_((x), sizeof (x)) | +voidcd9660_pad_string_spaces_(char *, size_t); Arguably you could have named the macro CD9660_PAD_STRING_SPACES() and used that instead. | Index: src/usr.sbin/makefs/cd9660.c | diff -up src/usr.sbin/makefs/cd9660.c:1.21 src/usr.sbin/makefs/cd9660.c:1.22 | --- src/usr.sbin/makefs/cd9660.c:1.21Thu Nov 6 23:45:17 2008 | +++ src/usr.sbin/makefs/cd9660.cThu Nov 6 23:49:40 2008 | < at >< at > -689,6 +689,12 < at >< at > cd9660_finalize_PVD(void) | /* 16 "0" + one NUL */ "0000000000000000", 17); | | cd9660_time_8426(tim, diskStructure.primaryDescriptor.effective_date); | + | +memcpy(diskStructure.primaryDescriptor.application_data, | + "[APPLICATION USE]--> ...", 24); | +memcpy(diskStructure.primaryDescriptor.application_data + | + sizeof (diskStructure.primaryDescriptor.application_data) - | + 24, "... <--[APPLICATION USE]", 24); For robustness, wouldn't it be better to provide a #define for those strings, and use sizeof(STRING)-1 rather than the hard-coded "24" ? (This is a general comment; I see similar use of sizes elsewhere in your changes.) Luke Mewburn 2008-11-10T06:29:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.miros.general