<OriansJ>fossy: if you were planning on doing it, go for it; I'll find a different thing to work on tonight. <OriansJ>rain1: you can always check if S can be built by M2-Planet using the new M2libc <yt_> OriansJ: awesome, thanks! <yt_>OriansJ: I've just got the first bit of macro expansion working XD <OriansJ>yt_: well you got enough working to do a proper C stdio.h ^_^ <OriansJ>now just to export the architecture flag as a variable and you can do architecture specific behavior <yt_>OriansJ: hmm, not sure what one needs for a stdio.h? but sure, nearly there :p <yt_>as long as you don't do #define BAR 1 #define FOO BAR it should mostly work. I haven't figured out how I'm going to do the rescanning <OriansJ>Just need to get the AArch64, armv7l and AMD64 to get to matching levels in unistd.h and fcntl.h as x86 but that just requires a block of effort <yt_>heh, I'm going to have to skip CONSTANT lines now. this doesn't parse for some reason: CONSTANT 1 1 XD <OriansJ>yt_: we only need to support the features we want to use <yt_>#define EOF -1 doesn't work? <OriansJ>give it a try if you don't believe me <yt_>on it, on it :) just checking if that's what you were saying <OriansJ>but that is just because CONSTANT never was taught how to handle it <OriansJ>I could have used 0xDEADBEEF for EOF and it would have worked <yt_>ah, I see now, that should be solved with my next patch :-) <OriansJ>(as long as the READ and EOF agreed on what EOF was) <OriansJ>at this rate, I'll just need to add bitslices to M2-Planet to be able to compile TCC ( or just rip them out of janneke's TCC fork ) <yt_>OriansJ: won't we need #include to build TCC? <OriansJ>in fact it'll only get in the way long term <OriansJ>I can concat a list of files into a single file and compile it the same on bare metal as I can on an OS <yt_>ah of course, just needs carefully written M2-Planet invocations <OriansJ>with an eye towards the future, where we are going to have to build TCC on bare metal to bootstrap a proper Kernel <yt_>getting M2-Planet to the point that we can jump straight to tcc would simplify the bootstrap graph a lot <yt_>stikonas: we're not there yet! <yt_>ah sorry, misread what you said <stikonas>I probably wasn't very clear above... Anyway, no worries <yt_>ho hum, some of my pointer mangling is still a little bit off; but that'll do for tonight. should be able to make some more progress over the weekend <Hagfish>building TCC on bare metal will be so epic <stikonas>yeah, after that it's clear, tccboot linux and you are done... <OriansJ>It would be much easier if we went the M3 route to bootstrapping GCC and a POSIX directly <OriansJ>but that requires me to build an Assembler with matching syntax to GAS that outputs ELF files that need to be linked by a linker before it becomes a working binary. <OriansJ>So much work to do, never enough time <OriansJ>perhaps, I am just making things too hard for myself by going for the gold but what is one more "impossible" project after so many? <Hagfish>all things being equal, i think it would be best to optimise the project for "contributability" (or a word which means something similar) <Hagfish>you know the old saying about "if you want the correct answer to a question on the internet, then give the wrong answer and wait for someone to correct you" :) <Hagfish>(obviously security / auditability should be one of the highest goals, but making the steps easy to understand will of course making it easier for new contributors to get up to speed) <Hagfish>so i think it's better to put something out there and have it catch people's interest, and then when they look at it make them think "huh, i could do better than that!", and then accept their patches :) <Hagfish>but of course the other thing to optimise for is the enjoyment of the people already doing the hard work, so i wouldn't dare suggest that should be compromised on *deesix wonders about #include "foo.h" vs -f foo.h <deesix>static objects are local to the translation unit, I think <deesix>So if a file is included several times, just one -f is not the same, isn't it? *deesix wait for someone to correct this :P <deesix>In other words, I think concatenating or -f'ing is not a general solution. <deesix>Well, we're only doing one TU right now, so that would be the real problem in those cases. <deesix>Cases like both a and b including c, and me thinking on just -f a -f b -f c. <malina><OriansJ> So much work to do, never enough time <-- Amen <deesix>... where c has some static object. <Hagfish>"Google Pulls Parler as Apple Threatens the Same in Wake of Capitol Riot" <Hagfish>well, as long as the Duopoly only use their powers to ban apps that have speech i dislike, then this is fine and doesn't set any dangerous precedents <lfam>It’s a little surreal to see the traditional anti-censorship discourse newly applied to the most powerful man in the world right after he incited a mob that attacked a rival branch of government to overturn a free and fair election. <xentrac>it's surreal that some people have ethical principles they apply consistently? whoever wrote that needs to get out more :) <fossy>fixed escaping in kaem, stikonas[m] <fossy>janneke: is there a change that at some point we might be able to get an updated tinycc that allows REBUILD_LIBC to happen against master mes? <janneke>fossy: maybe we should remove the REBUILD_LIBC flag, it should always be true, be rebuilt <janneke>mes' wip branch will be merged when wip-arm-bootstrap is ready <janneke>mes' wip-m2 branch will be merged after that, when wip-full-source-bootstrap is ready ***ChanServ sets mode: +o rekado
<janneke>i'm hoping m2-planet gains global, local char foo[3]; static char foo[3]; support in the meantime <janneke>that would allow us to remove some of the ugliest m2-planet adaptions to wip-m2 <yt_>janneke: if you don't mind writing a few small test cases, I can see what I can do <fossy>stikonas don't worry too much if you can't get it working, but escaping most certinaly should work now <stikonas_>well, I just need to update submodule... to test <stikonas_>I guess it will be simplified too once you can use this escaping <fossy>stikonas_: tcc is coming along -- finished the rebuilding libc bit now (was a bit of a pain as bootstrap.sh's instructions didn't workk ootc) <fossy>now i just need to reach the fixed point <fossy>well the 0.9.26 is done, then just compile 0.9.27, done <fossy>stikonas_: if you are looking for something to do (no pressure at all), you could update blynn-compiler bc pder has kindly removed the need for shell redirection <fossy>(only if you are bored, i will do it after tcc if you dont) ***stikonas_ is now known as stikonas
<stikonas>fossy: ok, just tested kaem escaping, seems to work :) <stikonas>yeah, I can check that out... Breakfast first though <stikonas>it's already a bit late for breakfast here... *janneke pushes scaffold/{global,local,static-local}-array.{c,kaem} to wip-m2, for yt_ <stikonas>OriansJ: maybe worth updating mescc-tools in mescc-tools-seed to latest revision? <stikonas>kaem escaping seems to work much better now <OriansJ>Hagfish: well the one case where #include would be different than -f is if the #include is in the middle of code. Which is just a really bad code smell. <OriansJ>stikonas: I probably should update both M2-Planet and mescc-tools in mescc-tools-seed <stikonas>yeah, M2-Planet also had some updates... <OriansJ>Then try to find some time to get M2libc ready for integration <yt_>janneke: thanks! those help a lot to know exactly what you need. I might take a little break from the preprocessor and get some of that in. The global array doesn't look too complicated, so might start there. <OriansJ>janneke: thank you for reminding me I need to really start adding the catches for --bootstrap-mode <yt_>OriansJ: I'm just having a look at how to handle CONSTANT when the preprocessor is enabled; they end up conflicting badly if the #define is before the // CONSTANT <yt_>my current thinking is that it's probably cleanest to just ignore the whole CONSTANT line if bootstrap mode isn't enabled <yt_>I *think* it's then still possible to write code that compiles in M2-Planet with and without bootstrap mode, as well as GCC <yt_>ah no I can't just ignore the line, because the parser doesn't see newline tokens, bah <yt_>new plan. ignore // lines in the lexer when not in bootstrap mode <OriansJ>yt_: you'll instantly run into the pointer arithmetic problem if you do <yt_>OriansJ: yep, but I have #if to deal with it :-) <OriansJ>and the resolution for CONSTANT EOF 0xFFFFFFFF \n CONSTANT EOF 0xDEADBEEF is alway choose the last defined value <yt_>OriansJ: that resolution is the same for #define at the moment <yt_>but yeah, I do worry that this will end up being too painful <OriansJ>let us take a step back for a second. <OriansJ>first M2-Planet doesn't use *ANY* pointer arithmetic <OriansJ>So dropping of // CONSTANT lines will not be a problem for it <OriansJ>--bootstrap-mode will preserve the old behavior for working programs until we fix pointer arithmetic and they can drop the // CONSTANT lines <OriansJ>it would make M2-Planet more C compliant and people wouldn't be tripped up by their line comments becoming working code <OriansJ>So it is a very good idea going forward <yt_>Okay that makes sense <OriansJ>and if we ensure --bootstrap-mode behavior is preserved; it will be a net step in the right direction. <yt_>and you make a good point that if --bootstrap-mode actually disables the preprocessor, existing code (including the tests) will just keep working <OriansJ>it'll make cc_reader.c a little uglier in regards to // but it is a small price to pay <yt_>OriansJ: I'll include a properly working --bootstrap-mode (for # and // lines) with my next PR. <yt_>OriansJ: should all the tests run with --bootstrap-mode? Or should tests run both with --bootstrap-mode and without --bootstrap-mode (when that makes sense)? <OriansJ>yt_: well let us keep things simple for a minute and leave what has --bootstrap-mode as is and as new tests get added, they can opt for with or without depending on what they are testing. <OriansJ>yt_: oh and thanks to your recent work we can pull the // /* hack out of mes-m2 <OriansJ>looks like there is a regression in mes_macro.c; guess I got some hunting to do <yt_>OriansJ: uh oh! let me know if I can help hunt it down <OriansJ>yt_: I don't think it is caused by M2-Planet <OriansJ>as by checking out an earlier commit or just commenting out the macro expand phase in the REPL gets it back to operational status <yt_>OriansJ: ah! I misread that as cc_macro.c :-) <yt_>hmm if --bootstrap-mode affects the lexer (for // and # handling) the --bootstrap-mode argument needs to come before any -f arguments <yt_>OriansJ: this doesn't feel great to me <OriansJ>well we could have a function that does the // handling before preprocessing <yt_>sure, needs // adding as a token though, currently it just gets eaten <yt_>ok, I'll do that rather than fixing up a bunch of tests <OriansJ>Nothing like previous design decisions to bite me in the ass again... <yt_>OriansJ: requirements change, it's the only constant. hence designs must evolve <OriansJ>until they include a mail client/server... yeah I know. <yt_>or until they become a lisp interpreter <OriansJ>nope an ad-hoc implementation of common lisp <OriansJ>but delete the # to enable push and pop and magically mes-m2 is broken <yt_>OriansJ: is that with preprocessor changes in M2-Planet? <yt_>also does --bootstrap-mode properly now, which might help with your mes-m2 problem <yt_>I'm leaving the preprocessor alone for a bit now and look at janneke's feature requests <ullbeking>good evening all, i'm new to the bootstrappable project... <ullbeking>i am still learning about it, but i understand, for example, ken thompson's famous lecture and the meaning of this <ullbeking>i'm particularly keen on learning more about the "Maintaining GCC version 4.7" project <stikonas>I guess that means adding new architctures, etc when necessary. I don't think much is going on right now regarding gcc 4.7 <ullbeking>one reason is that I'm very keen to really sink my teeth into C++ (and C) <stikonas>well, feel free to work on in. It's just right now most of the focus was still on bootstrapping gcc <ullbeking>stikonas: i'm working very closely with the power9 architecture these days. <ullbeking>i wonder if gcc 4.7 needs updating in this respect..? <stikonas>not sure about gcc 4.7 but earlier bootstrap chain definitely doesn't support power9 <ullbeking>so would it be useful to bring gcc 4.7 up to power9? <stikonas>and it's up to you whether you want to work from the botton (hex0) or from the top (gcc) <ullbeking>i'm very interested in returning to this work and getting deeply involved with something so interesting <stikonas>bootstrapping chain is now very roughly like this: <ullbeking>by "returning" i mean returning to computer science <stikonas>hex0->hex1->hex2->M1->M2-Planet->mes/mescc->tcc->gcc (that's ignoring all the additional tools) <ullbeking>OK. I'll have to learn what these terms mean and do some research. <ullbeking>and the gcc internals manual is the best place to start? <yt_>ullbeking: what is the relationship between POWER9 and PowerPC? Do they share an ISA? <ullbeking>but this is literally /just/ the kind of project I have been looking to work on, when I accidentally bumped into it <ullbeking>i use a POWER9 workstation as my daily computer <ullbeking>and I am currently setting up a POWER8 server too <yt_>ullbeking: I know the feeling XD it's how I got sucked into doing the AArch64 port of the first stages of the bootstrap <yt_>ullbeking: not GCC no, just the tools further down in the bootstrap <ullbeking>yt_: what do you recommend i do to get started? <OriansJ>ullbeking: perhaps the question what seems like the most fun to you? <ullbeking>OriansJ: the this that seems most fun is updating the bootstrap chain (where needed) for POWER9 <ullbeking>i would first try to build the current thing and see what happens with that, and go from there <ullbeking>maybe the changes required are minimal, I don't know <OriansJ>ullbeking: well we have a couple places where you can do C compiler work if you are interested (M2-Planet, MesCC, TCC and GCC of course) <stikonas[m]>I think rain1 has script that builds tcc on top of your system... <ullbeking>OriansJ: I am very interested in C compiler work, and also C++ <stikonas[m]>Or you can check out fossy’s live bootstrap (builds inside initramfs) <ullbeking>wow, this is getting magically fascinating already ;-) <OriansJ>with M2-Planet being the simplest to port to your architecture, MesCC is in Scheme <OriansJ>good them MesCC would be very fun for you. <OriansJ>it is a C compiler written entirely in Scheme <OriansJ>janneke is the primary author of MesCC <OriansJ>There are a few minor things you might want to know about when generating binaries with MesCC. The C code gets converted to M1-macro assembly and then linked with hex2 *ullbeking is referring back up to the bootstrapping chain diagram *ullbeking looking briefly <OriansJ>yt_: your pull request has been merged <Hagfish>ullbeking: one thing that might help the project is if you keep notes of the things you learn, which we could share to help onboard new people who join the project later on <ullbeking>Hagfish: ofc. i'm a big note-keeper kinda person. <ullbeking>what documentation tools do you use, Hagfish ? <Hagfish>ullbeking: heh, just a load of text files, and a paper lab book <stikonas[m]>Well, it's not used for long, there is more advanced version in C, that one is larger <OriansJ>ullbeking: that is just a name we are using for the POSIX port of stage0 <stikonas[m]>Just got repo with some build recipes for POSIX bootstrap <OriansJ>it is a single git clone and done bootstrap to C compiler <stikonas[m]>It includes binary seeds and some other repos as got submodules <ullbeking>bootstrapping has always fascinated me, i'm so happy to finally be hands on with it :-) <OriansJ>ullbeking: we happily provide education and training if required. ^_^ <ullbeking>but would POWER9 be considered new architecture? <OriansJ>ullbeking: well I don't have a POWER9 (Or any POWER system honestly) and thus I haven't ensured POWER9 instructions would encode properly or address properly <ullbeking>ok, so it's worth doing then. great. thx stikonas and OriansJ . <OriansJ>for example when we ported to AArch64 we had to deal with pointer calculations and alignment rules <ullbeking>for P9 it operates in either BE or LE mode, so there's that too, which will probably be fun ;-) <OriansJ>if you are curious what M1 and hex2 support you can ask or look at the code since they are very simple programs <OriansJ>ullbeking: we support both Big and Little Endian instructions and Data <OriansJ>we have basic support for octal and binary encoding schemes too but they haven't really been tested too well <OriansJ>ullbeking: well it is how to bootstrap a C compiler from Nothing <ullbeking>i am happy to have an excuse to dust off my old copy of the dragon book <OriansJ>for x86, AMD64 and AArch64 (with a half done armv7l port too) <ullbeking>also, any recommendations for other compiler books are highly welcome <OriansJ>ullbeking: the C compiler we wrote in assembly is far simpler than you would imagine <xentrac>I feel like a lot of compiler theory is counterproductive because it makes the problem seem harder than it is <xentrac>Jack Crenshaw's "Let's Build a Compiler" is one that doesn't, but I haven't actually read it <yt_>OriansJ: for janneke's global arrays, I'm just going to stick a require(!BOOTSTRAP_MODE) in there. I think that kind of pattern is probably the simplest way to keep bootstrap mode correct *ullbeking is looking to see an overall picture of the hex1 stage <xentrac>reading it is probably better than what I did actually do though <ullbeking>21:22 <xentrac> Jack Crenshaw's "Let's Build a Compiler" is one that doesn't, but I haven't actually read it <ullbeking>this was the first book on compilers i read, in about 1994 :D <OriansJ>yt_: that or create a function called bootstrap_error with calls line error and the rest to make it easier to fix <OriansJ>ullbeking: hex1 is just hex0 with single character labels ;a and one size relative pointers %a to save the work of having to manually calculate jump offsets <ullbeking>OK, I'm going to spend a bit of time reading and absorbing this information <OriansJ>hex2 extends hex1 with long label names, multiple relative (!8bit, @16bit ~architecture specific and %32bit) and absolute ($16bit and &32bit) pointer sizes <ullbeking>I need to get deep into the OpenPOWER specs too <OriansJ>ullbeking: especially instruction encoding <OriansJ>for example we discovered the armv7l documentation actually was backwards <yt_>ullbeking: if you're mostly new to Power9/OpenPOWER, writing hex0 is a good way of getting your hands dirty :) <ullbeking>yt_: using POWER9 means my hands are constantly very dirty :-) <stikonas>yaeh, hex0 is very nice... It's basically a self reproducing program (binary code is basically equivalent to source code) <OriansJ>ullbeking: think of hex0 as the test: (can your instruction set be encoded in bytes) <OriansJ>and if so what details do you absolutely need to know <yt_>OriansJ: what awful instruction set cannot be encoded in bytes? I know AArch64 is painful due to both endianness and non-nybble aligned fields, but at least the instructions are byte (word even) aligned <OriansJ>yt_: pdp-1 (18bit instructions), pdp-8 (12bit instructions); pdp-10 (36bit instructions), etc <xentrac>but there are conventional ways to represent TENEX files on Unix, e.g. <yt_>all before my time, thankfully :p <OriansJ>There are a bunch of FORTH designs that have weird instruction encodings (13bit bits really?????) <OriansJ>hence I am only dealing with sane instruction sets that can be encoded in 8bit bytes <yt_>very sensible, keeps you sane" <yt_>where did that " come from. who knows?" <OriansJ>and partially why I am not dealing with RISC-V's immediate split the immediate into 3 pieces acros 4 bytes with a billion rules <OriansJ>yt_: 8bit bytes was IBM stretch then IBM 360 <deesix>"""especially instruction encoding for example we discovered the armv7l documentation actually was backwards""" I was always curious about this, OriansJ. Would you elaborate a bit? Maybe _yt can confirm... <yt_>we can do the AArch64 trick of just loading an immediate from a pc-relative offset <OriansJ>deesix: if you look at armv7l's instruction reference, the first byte is condition code and the first 4bits of the instruction. (Something that should work really well with M1+hex2) <yt_>deesix: no worries. turns out yt was already taken, but I liked the handle enough to keep it, but it is a bit confusing, my apologies <OriansJ>but in reality it is the last byte of the 4 byte instruction <OriansJ>ullbeking: take your time, we will be here <yt_>OriansJ: is that due to endianness? <OriansJ>yt_: sorta word endianness but not byte endianness <OriansJ>See the armv7l instructions are little endian words but big endian bytes <yt_>OriansJ: enough to give you a headache <OriansJ>no but it threw me for a couple hours <OriansJ>I was so looking forward to arm assembly after dealing with x86 being everything octal aligned and AMD64 not having consistent octal or hex instruction alignment <OriansJ>then reality hit. then got hit with that armv7l immediates are instruction dependent too <OriansJ>as branch ~label and load @6 had different coding rules <OriansJ>so we had to do ^~label and @5 to make it sorta work <yt_> ^~label turned out to be useful for AArch64 too, except someone decided we needed 2 more bits for the relative offsets, so negative offsets needed fudging XD <deesix>I really like how you solved that, yt_ :) <mihi>ullbeking, as you said you love Scheme, you may also have a look at the psyntax.pp bootstrap problem in the Guile Scheme interpreter. That's not low-level, but rather high-level bootstrapping. The current implementation requires to have a pre-expanded version of it to compile the new version. I guess it might be possible with the already available Guile syntax primitives to write a psyntax implementation that only uses macros and use <mihi>that implementation to bootstrap the real thing, but so far (trying for ~10 days) I've not been successful due to my Scheme being too rusty. <mihi>that 10 days is wall clock, the actual effort was only a few hours so far. <mihi>OriansJ believes the easiest way to solve psyntax.pp is write a syntax-case expander in C. Long term will tell who is right :D <fossy>this whole time the issue i have been running into with the first part of the bootstrap was that i wasn't escape quoting the flags to tcc <fossy>it def didn't seem like that tho <OriansJ>fossy: not dumb, just human like the rest of us <fossy>stikonas[m]: yeah you did mention about how you needed config.h n stuff but for some reason even with config.h tcc still didn't work, but -D XYZ=\"abc\" does <fossy>before i was doing -D XYZ=abc <fossy>tcc 0.9.26 is done, i'll push when this build finishes and then do 0.9.27, then we're off to the races <stikonas[m]>We might switch mes to -D too instead of shipping config.h <fossy>yes, now that kaem escaping works <stikonas[m]>Once we have gzip, tar we can just preget tarballs instead of git submoduling everything <OriansJ>I am just going to punt on the mes-m2 macro expansion problem for a minute in mescc-tools-seed <stikonas[m]>I briefly tried to get qemu on aarch64 working but couldn't get any output :( <fossy>stikonas[m]: please do get started one i push but the final version will need to go against 0.9.27, hich is for the most part a drop in replacement but less buggy (read: required for gcc). <fossy>drop in replacement for 0.9.26 <stikonas[m]>Yeah, it's fine... It will be in the same path anyway <malina>fossy, where is that tcc repo if you have it somewhere? <malina>ye, I am sitting now and kinda trying to figure out this mes stuff :) as I say, the guile,scm,mes, all that is alien to me, but trying to ake ends of it. Gave otcc a go with M2-Planet, but that didn't go well ,p <yt_>malina: trying to compile tcc with M2-Planet is very brave <yt_>maybe one day we'll get there <malina>a precursor but ye it didn't go well, I also saw it relied on some of the stdlib, stdarg etc, it had comments which I see from above, (not sure if they haveit done but saw some work on it yest?) <fossy>sorry that it has taken a while, stikonas[m] <yt_>malina: I'm slowly adding features to M2-Planet to make life easier, mostly for janneke's wip-m2 branch of mes <stikonas[m]>I did that Haskell stuff although it was just copy paste <stikonas[m]>Diff between go.sh and blynn-compiler.kaem is very small <fossy>gforce_de1977: yes, that is the one i linked to <malina>is it with that patch which #ifdefs bootstrap then static compile = 1 kinda thing? <fossy>then we use that to compile the real tinycc <malina>just realised I have guile installed a long time, I was thinking, right.. better create a static package for this then :D <fossy>static guile is very hard to make <fossy>idk, i had to fiddle with makefiles and stuff to make a static guile <malina>do you recall what size it clocked in at? <fossy>including or excluding the precompiled modules <malina>(I mean only if you happened ot have it lying around) nevermind now. <malina>I onestly have no idea, but anything which would be partof the 'full package' <fossy>when i did it statically linked against musl on i686 <malina>I mean, my system package, which is dynamic and I don't know what is in it to be honest, is 45m <malina>but anyway 20-50 is within reasonable for me <fossy>tthis was a very minimal install too <malina>20 definitely is nice, musl is leaner ye. actually my init here (superman) is a dietlibc static binary if I set it to static <malina>init-env -dyn and is back on my (glibc) system <malina>been running the static a lonnnng time though as it just is , I mean, I always compile and install right into my only box, for half a decade, so it MUST survive. static one just seems probabnly a little bit more 'resolute' :) <malina>root 1 0.0 0.0 512 404 ? Ss 18:03 0:17 init /init <yt_>OriansJ: silly question but what is the proper way to define FILE in non bootstrap mode? A typedef I guess, but to what? <ullbeking>mihi: thank you for suggestion re: scheme :-) <yt_>mihi: thanks! I was looking for that but couldn't find it <ullbeking>i'm going to read up, around, sideways, all over the place, and orient myself to all of this... it's fascinating!! <malina>configure: error: 'mescc' failed to compile conftest.c. in tinycc. gforce_de1977 , I used something rain1 pasted a day or 2 ago , which patched volatile out of conftest.c but then this happens. <stikonas>well, fossy will soon push his build recipe <gforce_de1977>malina: i remember: (substitute* "conftest.c" (("volatile") "")) <OriansJ>ullbeking: always ask questions if anything isn't clear in the bootstrap because all of it must be beyound question. <ullbeking>thank you for being so supportive, OriansJ :-) <ullbeking>right now what I'm doing is trying to get a view of the forest, and... <OriansJ>ullbeking: we love developers here ^_^ and we want to help them as much as possible <ullbeking>to look at build tools, build chain, and setting up qemi <ullbeking>22:42 <OriansJ> ullbeking: we love developers here ^_^ and we want to help them as much as possible <malina>clearly using the right perfume there OriansJ ! ,) <malina>no, I can confirm ullbeking , he does , along with janneke and the lot in general, to be fairly positive peeps :) <malina>on a side note, is od always big-endian? <ullbeking>i am getting a very positive vibe from this channel, i love it here already :-) <ullbeking>one thing i confess is that i don't know qemu as well as I should, so I should probably go and learn some of qemu now :-) <ullbeking>is qemu an important part of your toolchains and build environments, folks? i mean, for people who work on bootrappanble projects? <stikonas>qemu is only used in live-bootstrap, and only so that we don't need to reboot <stikonas>otherwise you would have to reboot into it there <stikonas>so you don't really need to learn qemu. You can if you want but not required here <mihi>ullbeking, you probably want to use some kind of virtualization software when testing bootstrap scenarios, but it does not have to be qemu (I use VirtualBox) <mihi>(yes I know, not part of Guix due to bootstrapping issues for its virtual BIOS) <ullbeking>my power9 workstation needs a bit of maintenance becaiuse i've bricked the BMC (ouch!), so i'll work on other isas first <OriansJ>you can do everything in Scheme, C or you can get down to the metal <OriansJ>ullbeking: well that is a much bigger problem than a C compiler <mihi>ullbeking, once you have a C++ compiler, the bootstrap is probably done :D <stikonas>simplest way to bootstrap C++ compiler is to use gcc 4.7 <ullbeking>this is a little side topic.... but i have a belief that lisp programmers and c++ developers converge totally in some very near universe <OriansJ>ullbeking: only if C++ gains proper garbage collection and Scheme finally gives up the parens <OriansJ>but all languages converge on the problem of getting humans to write code together without making a huge mess or die hoping to survive on the brilliance of a few minds. <ullbeking>this is why i hate snobbery in software and i have so much respect for software that works resiliently or even _at all_ <ullbeking>ofc a professional strives to improve but.... <ullbeking>i don't like it how so many devs have this syndrome where they prefix every introduction to some presentation of their code with... <OriansJ>ullbeking: well people who feel that they have to justify the tools they use, usually do so because they fear people will discover they are bad programmers. But the truth is all humans are bad programmers but it is ok, approximation towards solution usually works. <ullbeking>"this is really crappy code and it should be better, but here it is." <ullbeking>the fact that you put yourself out there and make a serious effort is enough to gain respect from me <ullbeking>i'm trying to think of what my first task should be <OriansJ>ullbeking: well even Knuth's perfect code still has bugs <OriansJ>ullbeking: your first task is to have fun <ullbeking>OriansJ: i think literate programming was one of his greatest contributions ever <OriansJ>fossy: seL4 the proof had a flaw and a buffer overflow vulnerabity because of it <fossy>proving the proofs time :P /s <OriansJ>even Millions of dollars and 10 years doesn't mean all bugs are gone <fossy>ullbeking: which power9 workstation do you have? <ullbeking>in practical terms, i need to flash the BMC chip on my workstation, maybe even tomorrow <OriansJ>my wife would kill me if I bought one before I paid off the house <deesix>ullbeking, I used a bit of qemu user mode emulation during development, but for low level stuff you really want to test on the actual hardware (the emulation sometimes isn't perfect due to bugs or optimizations). <ullbeking>i realized that there is some low hanging fruit for updating the gcc 4.7 bootstrapping chain for power9 <ullbeking>deesix: yes, i agree 100%, always have. especially with the kind of work i do (audio dsp)