<OriansJ>because if someone could build tinycc or pcc with one of those or an extended version of those. I could manually implement one of them in assembly <OriansJ>rekado: any C program that sticks to structs, pointers, ints, bytes and strings can be manually converted to assembly by me <bavier>all these people with their c compilers, and I'm still just getting mine started <OriansJ>bavier: just please don't bother to implement the full C syntax <janneke>oh my...are we going to have a smorgosbord of C compilers <bavier>OriansJ: yeah, I'm targeting tcc or 8cc <OriansJ>bavier: I'd love to see what you have <OriansJ>janneke: the problem is that most of them require a preprocessor and I don't know a single person who is willing to write one in raw C <janneke>OriansJ: Nyacc includes a C processor :-) <janneke>It's only dependency is a decent Scheme...like Mes ;-) <rekado>civodul: I also like it. Its terseness might be a problem in some cases, but it does a much better job than their license chooser. <OriansJ>janneke: dumb question but would it be possible to strip Nyacc down to just a C preprocessor and minimize the level of lisp required? <janneke>OriansJ: I would really like to get Matt Wette involved in [our] bootstrapping discussions <janneke>Nyacc has quite heavy Scheme dependencies, like syntax-case, R7RS ellipsis, fluids, regexps even <janneke>that makes sense when you don't have bootstrapping in mind, of course <OriansJ>janneke: hence the question of just the preprocessor part of Nyacc. Aka we use lisp to function as a C preprocessor and then can use a stripped C compiler <janneke>OriansJ: I think that should be possible...not sure though why you wouldn't [want to] write the rest of theh C compiler in LISP/Scheme too? <janneke>Having cpp available in Nyacc (it's not finished but Matt has worked very hard on it the past months) is of course a great start! <OriansJ>janneke: it is always easier to implement a C preprocessor and a single file C compiler than a single step C compiler <janneke>OriansJ: ah, I see. You just want to have the option of having a separate cpp <janneke>that makes sense; we'll have to ask Matt! <OriansJ>janneke: exactly, and it should really simplify the problem <OriansJ>no need for #define, #include, or any conditional compilation logic at all <janneke>OriansJ: sure, that's how Mes's c compiler (Mescc) works; Nyacc simply provides an AST; cpp stage is handled implicitly by nyacc <gazon>CharlieBrown: I don't know. The speaker (that link is a presentation slide) was talking about FSF endorsed distros being the most resource constrained link in a chain of security updates from source to user. Those distros are less secure as a result. <buenouanq>Knowing GuixSD exists and how great and beautiful it is, I can't in good conscience recommend anything else to anyone anymore. <gazon>CharlieBrown: that presentation slide thing is javascript driven <gazon>CharlieBrown: what, the javascript? <gazon>buenouanq: I am close to replacing Trisquel with it, but, as a non-scheme literate software dev, I am trepidatious. <CharlieBrown>gazon: Welp. It's nonfree, then. Could you contact the maintainer? <CharlieBrown>gazon: Also, which MIT license are you speaking of? The Expat license, or the X11 license? <gazon>CharlieBrown: Expat probably. It just says MIT which, given it's hosted on github, means expat. <buenouanq>gazon: You don't have to know any scheme to use GuixSD as your primary OS. <buenouanq>You're missing out as is though just for the mere fact that you don't know Scheme ┐( '~')┌ <gazon>buenouanq: true on both counts, but I still need to be able to build software, fire-up virtual machines, etc. and it seems to me that if I need a package in a hurry then I need to known guile to get one made. <gazon>which I am beginning to learn. <CharlieBrown>Hey, where's that vid where someone completely hardens an X60 and it becomes nearly useless? ***Piece_Maker is now known as Acou_Bass
<kadintrooper>Anyone know if someone has a package description for tdesktop laying around anywhere? I'm having difficulties importing it from nix <CharlieBrown>Sigh... I need to make a multiboot flash drive with all the libre distros on it. <kadintrooper>Whenever I try using guix import nix I get a stack overflow <kadintrooper>ice-9/boot-9.scm:68:2: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'. <reepca>Which of the GSoC suggestions would you recommend for a sophomore computer science student who's been learning lisp (specifically common lisp) in their free time? <reepca>Hm, unfortunately they aren't quite certain where the balance between "too hard" and "can't fill a summer with it" lies. Both because they aren't certain of their skills and because they aren't certain of the difficulty of the tasks. <reepca>The build tool seems like it would require the least specialized knowledge, but I don't have a very good idea of the scope of the project. <reepca>Specifically regarding the build tool, it says "... should ultimately be able to run complex workflows on multiple servers and...". What exactly is meant by that? That the build process should be able to be distributed across servers? <janneke>reepca: I guess, but better ask later when more of GMT+1 is awake ;-) <reepca>Alright, I've just got myself in a bit of a pinch here with delaying so long getting this stuff figured out. <janneke>but esp. wrt to your remark of striking the balance, I believe that if someone chooses a project that they really want to do, they can accomplish amazing things -- whereas when it's `just work' they will `probably do okay' <janneke>and there are mentors to help with any questions, of course <rekado_>even the rebuilt icecat crashes whenever I load up any web page. <rekado_>segfault and sigpipe, dependent on which URL. <janneke>rekado_: when oh when do we get a sensible browser built in emacs <rekado_>heh, it just moved up a couple of steps on my TODO list :) <janneke>i've been using conkeror for a while now, and it's a fair prototype of what is possible <ofosos>rekado: hmm, seems to be a general problem, should i hit submit crash report or is this going to /dev/null? <rekado_>ofosos: I’m using icecat from core-updates. I don’t have these problems with icecat from master. <rekado_>I don’t think the crash report thing actually works. <ofosos>grml, i'm having constant crashes <rekado_>ofosos: in about:config search for “cairo” <rekado_>ofosos: do you see any entries that match? <rekado_>if so, you can try to change the values to “skia” <ofosos>yep, it's gfx.canvas.azure.backends <rekado_>changing this to “skia” has solved the problems for me <janneke>catonano: do you notice the sha256 mismatch? <catonano>I don't understand hhow that is possible. I was trying to bild a vm image <catonano>the hash declared in the linux-libre-4. definition is 19x6hasx7... <catonano>and the downloaded tarball has 1864sbq2r... <catonano>how iis that possible ? Wasn't the kernel package checked ? Or is the tarball changed ? <rekado_>efraim: it seems that the change in wxwidgets from the old webkitgtk to the latest webkitgtk broke the webview, webkit, and webviewwebkit features. <rekado_>efraim: this causes aria-maestosa to fail. <catonano>it's 4.9.19, the definition is for 4.9.18 <janneke>catonano: i also get hash: 1864sbq2r5y7fi26hla9k4avzs6sprkpgwpq8gi0sr39i58z6hnz <catonano>janneke: I downloaded and hashed it locally and I get the same hash <janneke>we'll have to ask mark_weaver about this commit <janneke>commit f62acf1eb7ae9f3a582e897abbbfb229f112b31e <catonano>anyway, I just moved to "linux-libre" and it works. It ust built an image <catonano>in the aternoon I'll try to run that image <janneke>catonano: sure; good to bring this up; possibly post to guix-devel <OriansJ>janneke: have you considered the idea of a lisp compiler written in lisp? <janneke>OriansJ: paroneayea mentioned that to me; i briefly looked at preScheme <janneke>in fact, that's one of the most difficult things about full source bootstrapping/Mes: there are somany possibilities <OriansJ>janneke: Why not choose what looks easiest? <paroneayea>rekado_: glad to keep the boring dreams going :) <paroneayea>rekado_: and yeah I've thought of maybe adding something CLIM like to emacs w/ EIEIO <OriansJ>janneke: literally the most trivial single step solution. Then we can work on the step before that <janneke>OriansJ: why not indeed? That's exactly why I chose Mes... <[df]_>hard to tell what's easiest without trying, but that I think that's what janneke's doing <janneke>[df]_: yeah...it's the `looks' in OriansJ's `looks easiest' <janneke>it very depends upon who is looking, and what things are already there to see <janneke>i can easily imagine that nothing of current Mes will remain one year from now <janneke>I's just: writing a scheme interpreter seemed easier to me than a lisp compiler <janneke>and that I figured: we need a C compiler, and if I'm to write one it will be in scheme <[df]_>it's great that someone's putting in the effort to explore it though :) <janneke>indeed, we have several someones, which is even much better <OriansJ>janneke: that is because writing a compiler is 20 times harder than an interpreter <OriansJ>for example, someone could write a C interpreter much faster than they could write a C compiler <OriansJ>Hell with some creativity, anyone willing to hand write a C parser could convert my lisp interpreter into a C interpreter with a couple weeks of work <OriansJ>[df]_: With stage0, one only needs to audit 2792 bytes for a full assembler <jmi2k>How can I use qemu kvm without sudo? <[df]_>will have to look into it more when I'm more awake <OriansJ>The hex0 files are just pure hex (any hex compiler can build them), the hex1 have 1 character labels and hex2 have long label support <janneke>OriansJ: so if we use stage0->lisp; we only need to trust ~3kB <OriansJ>[df]_: it is completely portable, produces identical results on PowerPC, MIPS and x86 <OriansJ>janneke: less than that actually (280 bytes) <OriansJ>everything else has full source and comments relating each line of hex to its assembly code with a direct 1:1 relationship that makes auditing easy <janneke>it should be quite easy to translate mes.c scheme interpreter into your lisp <OriansJ>stage0 even has a hand written text editor for those wishing to do a complete hardware level bootstrap with no other sources <OriansJ>janneke: performance, would only matter if we needed to run that code often <janneke>it would be nice if we could build tcc in less than a week or so, though ;-) <OriansJ>However, stupidly simple code is written faster than code that runs fast <OriansJ>I'd rather waste CPU cycles than programmer cycles <[df]_>bootstrapping is worth taking time over <OriansJ>We can always go back and improve the performance after it is working <janneke>ACTION has nailed two problems running Nyacc's cpp on mes <janneke>looking at your lisp.s...do you have some example programs that it can run? <OriansJ>and I can add primitives pretty easily <janneke>beautiful -- so much fun to read your take on minimal list! <ZombieChicken>Anyone else notice how guix system reconfigure's tab completion is broken out of the box and you can't tab complete the config file? <janneke>wow, that looks actually like code i could understand -- need a bit more time <OriansJ>janneke: yep and it perfectly collects everytime <OriansJ>took about a couple hours of thinking but only about 20 minutes to write. <janneke>took me two weeks or so to write mine (well, an afternoon to write, rest to remove bugs) <OriansJ>janneke: the benefit of trying to solve a simpler problem <janneke>the current version has some workarounds and ifdefs for mescc, this is last clean version: <OriansJ>janneke: I like it, probably runs faster than mine too <janneke>the up/downside is that mes uses index-based cells, you are using pointer-based car/cdr right? <janneke>OriansJ: it's actually stop-and-copy `straight (cough)' from SICP <OriansJ>janneke: bingo and my has a fixed number of cons cells that never move <OriansJ>garbage_init literally just takes a chunk of memory and says here is all of the cons cells you will ever need. <OriansJ>using free_mem, you can see exactly how many cons cells your expression consumes <OriansJ>toss it at the end of a begin and you'll see how many cons cells your expression evaluation requires. <OriansJ>Which means (minus the memory space consumed by input/code) the memory space is constant <ZombieChicken>Is there any way to get to a terminal when using X? It's just dropping me in a login screen w/o any apparent way to get a terminal <OriansJ>ZombieChicken: you can use tty1 or tty2 and run xfce4-terminal --display :0 to spawn one <ZombieChicken>I was trying to get to a TTY. The problem is I don't have a terminal installed for root, and would prefer to just not use X for root anyways <OriansJ>ZombieChicken: Ctrl+Alt+F1 or Ctrl+Alt+F2 <ZombieChicken>OriansJ: Thanks. I can't test that because I'm in a VM and it switches my host system's terminal. <OriansJ>ZombieChicken: what virtualization software? because you could leverage key capture <ZombieChicken>OriansJ: qemu w/ -usbtablet so I don't have to deal with input capture. I know why the problem is a problem, so I'll just avoid it for the time being <ZombieChicken>Great. sudo -i works, then my "L" key no longer works in the terminal... <ZombieChicken>Had to kill the term then start a new one to get that back... <OriansJ>ZombieChicken: You know you can tie keyboard capture release to a single key (like mod4) right? <ZombieChicken>I'm dding the .img to a USB and I'm going to reboot to test it in a few <OriansJ>ZombieChicken: mod4 was just an example, you could do things like F12 or Caps Lock <OriansJ>Wow, I am dumb. I just realized I implemented line comments for my lisp in assembly but didn't bother to add it to the C version >.< <ZombieChicken>OriansJ: For the sake of everyone, think about implementing docstrings. They can be really useful <OriansJ>ZombieChicken: It is a lisp written in assembly that is only 6320 bytes large <OriansJ>Think stage0, everything one needs from a 280 byte hex monitor to fully working forth, lisp and eventually complete C able to compile gcc <ZombieChicken>Maybe I havn't had enough coffee this morning, but are you saying you're wanting to build GCC w/ this lisp of yours? <OriansJ>ZombieChicken: No, I am wanting to help others build GCC using a minimal bootstrap binary and a complete chain of trust <OriansJ>making a lisp and a forth are just attempts at helping others in the achieving of this goal <OriansJ>I'll even do interpreters and compilers for other languages if they would help in that goal. (I even wrote a text editor in assembly for those doing bare metal bootstraps) <OriansJ>ZombieChicken: PowerPC, MIPS, SPARC, x86, AMD64, RISCV, 6502, z80, etc <OriansJ>ZombieChicken: good at what exactly? <ZombieChicken>Honestly, anything other than x86/64 would be good today. We need a new arch that isn't insecure by design <OriansJ>ZombieChicken: yes but please understand nothing of use is 100% secure. It is only about how expensive it is to compromise the system <ZombieChicken>I'm aware, but crap like Intel ME is just flat broken by design <OriansJ>ZombieChicken: Then buy an IBM x200 and install Libreboot <ZombieChicken>When I get the money I'm probably going to look at getting a Novena <rekado_>(I have an x200 and it’s not the best machine to be constantly compiling software; but other than that it’s fine.) <ZombieChicken>Having run Gentoo on a 2.5GHz P4 once upon a time, I'm here to say you can compile software on almost anything with enough patience and proper nice levels <OriansJ>ZombieChicken: then buy the Vikings D16 Mainboard <ZombieChicken>OriansJ: I'm unfamiliar with that board. What CPU does it use? <OriansJ>ZombieChicken: What is wrong with 32 core and 256GB of Ram for a desktop? <ZombieChicken>OriansJ: My desktop already predates the ME-style backdoors, and supporting obsolete hardware does no one any good <braunr>well i have, and have seen, lots of old hardware in use <OriansJ>ZombieChicken: Some people actually value their freedom, even if it is inconvient or costs more <braunr>which is reasonable for what it is <ZombieChicken>OriansJ: Yes, but suggesting a constantly dwindling supply of outdated systems doesn't help matters. Better to spend the money on open hardware and non-x86 systems than sinking it into old, refurbished hardware <OriansJ>ZombieChicken: That is why RISC-V Systems are being developed <braunr>if that non-x86 system is actually more advanced than the old refurbished hardware <ZombieChicken>I understand why old hardware is suggested, just stating that the money is better put in other places <braunr>people seem to severely underestimate all the research put into that old and quirky total-store order architecture in order to make it that fast <janneke>ZombieChicken: won't that take some time? <ZombieChicken>OriansJ: As I understand it, RISC-V isn't there yet, and I'm not aware of a production-ready system that's using it <OriansJ>ZombieChicken: Some people want freedom now and that might consume some money that might be better invested for freedom later but that is their choices <ZombieChicken>janneke: Time and money, but I'd hazard a guess and say that money is one of the bigger problems <janneke>aren't those the options: spend money to get freedom now, invest money to get freedom later? <OriansJ>ZombieChicken: New hardware is expensive and takes time <ZombieChicken>OriansJ: and won't be developed if there isn't a market for it, thus putting off the time when it's actually viable <janneke>ZombieChicken: money is a means, there's plenty of it if you have a good plan <braunr>i think time matters more actually <OriansJ>ZombieChicken: there already is at the low end <braunr>and most people don't do things that require true high end hardware .. <ZombieChicken>janneke: Yes. I'm just suggesting we're better off looking for new systems than sinking money into old. <OriansJ>ZombieChicken: You can buy a high end Power System right now if you wanted <ZombieChicken>braunr: Define "true high end hardware". Are we talking gaming rigs here, supercomputers, or massive clusters ala Roadrunner? <ZombieChicken>OriansJ: I'm aware. I'm also aware of the cost of those systems. <braunr>or play games that don't need the latest stuff <braunr>and considering the very low quality of game code, don't expect it to be ported to arm without lots of accidents <ZombieChicken>braunr: "most", maybe. I've argued for some time that most people would be happy with a 1ghz p3 and half a gig of RAM if software wasn't bloated <braunr>what's the problem with the old vikign stuff ? <OriansJ>ZombieChicken: There are no "Clean" solutions, only a community trying things together <braunr>OriansJ: i don't mean to be harsh, but i really don't see how those proverbial answers could help anyone :/ <ZombieChicken>1) it's already outdated, so if something goes wrong finding a replacement will become steadily harder, 2) unless you're unfortunate enough to have a "modern" ME-included system, you're better off spending the money on something with a future, like ARM or whathaveyou <braunr>1/ is countered by the fact that lots of those are still around, well supported <braunr>they're actually reference platforms for "outdated" <braunr>2/ no, the future is full of bugs, if you want something that works, you want old <braunr>and i insist again on total-store order <braunr>x86 by design makes parallel code less buggy <braunr>most programs just explode when ported to smp arm <braunr>and finding those bugs can take a _huge_ time <braunr>where x86 is already much faster, with the increased guarantees <ZombieChicken>As OriansJ pointed out, there is more than just ARM out there <braunr>what's the subject of the discussion ? <ZombieChicken>I think it was whether it's better to spend money on old hardware or x86/64 alternatives <OriansJ>braunr: I think the problem is that we need a better sales pitch in regards to hardware to win the mass consumer market <braunr>"win the mass consumer market" ? <ZombieChicken>That won't happen unless Intel, AMD, MS, et al basically blow up <braunr>well i'd definitely go with old x86 <ZombieChicken>On a somewhat related note, is there a working RISC-V system out there, or is it still an acedemic research project? <braunr>i don't know what your job or experience is, but as a "real-time embedded engineer" (yeah the full blow J2EE-arrogant like label), i've seen lots of things <braunr>the only real problem for "freedom" or rather, security, is sms <ZombieChicken>I've heard arguements to the contrary from Big Iron sysadmins <OriansJ>ZombieChicken: Yes, I have one that I got for $55 <braunr>ZombieChicken: i don't know what to tell you <braunr>i program operating systems, and i've been working with a friend on performance monitoring for some time <ZombieChicken>braunr: Honestly? It may just come down to the difference in needs between mainframe needs and embedded needs <braunr>uh no, i'm not talking about embedded needs <braunr>that's just my job, but i've seen all kinds of things <braunr>and i'm certainly not talking about "embedded x86" <braunr>i'm talking about low-to-high end processors <ZombieChicken>braunr: Regarding your previous comment about x86 parrellel code blowing up on ARM, is that absolutely a flaw in ARM, or a flaw in execution (either from the compiler, interpreter, or programmer)? <braunr>because arm has a very relaxed memory model, the most relaxed after alpha <braunr>whereas x86 has the most restrictive <braunr>which should make the arm perform better <braunr>and somehow x86 (actually more intel) processors are orders of magnitude faster <OriansJ>braunr: Sounds like lazy developers with bad hardware assumptions <braunr>(for the arm implementations i've seen though) <braunr>i wouldn't say "lazy developers" <braunr>schools don't teach properly, specs are very, very hard to understand, and very permissive because they aim at "performance" <ZombieChicken>Considering the difference in funding and difference in age between ARM and x86, I'm not suprised x86 is faster <OriansJ>braunr: The reason Intel has top performance is simple Marginal_R/D * Unit_Volume <braunr>and the industry demand is so high that low quality just does the job <braunr>ZombieChicken: i'm surprised that it *can* be faster <ZombieChicken>braunr: "low quality just does the job" unless it doesn't, in this case... <OriansJ>braunr: 1M chips * $50 of research per chip equals $50M on design. <ZombieChicken>What you described sounds like a compiler issue as much as a developer problem <braunr>all my years have been filled by "what the fuck" moments where a torvlads-like manager would have fired everyone <braunr>OriansJ: money alone doesn't make everything possible <braunr>no i mean someone who says "shit" every three sentences and is extremely demanding <OriansJ>braunr: right but it generally pays for very smart people to do lots of hard work to create something the market place wants <braunr>it's easy to see how he handles management, even if it got a little better recently <braunr>OriansJ: yes, that's the real metric <ZombieChicken>From what I've seen, Torvald's management skills are similar to a pack of hyenas. Screw up and they eat you alive <braunr>some people argue that the c spec is too permissive <braunr>but it's generally agreed that c is meant for system programming <OriansJ>braunr: Intel flat out spends more money than any other Company on the planet for CPU Design. <braunr>for c++, i'm not sure what the general idea is <braunr>ZombieChicken: no you need to die in a fire :p <braunr>including what you just said hehe <ZombieChicken>When I need to reimplement half the standard library to get something secure, there is a problem <braunr>but as with any language, you gotta do things right <OriansJ>ZombieChicken: braunr: C is just a winner because of its relationship to Unix. <braunr>in particular, when the language gives you sizeof, you gotta use it <braunr>c is a winner because it's a thin layer above the processor <ZombieChicken>braunr: The problem with C is that there are so, so many ways to do things wrong <braunr>which means there are only a few ways to do things right <braunr>i would use your argument against c++ and other "multi-paradigm" languages <braunr>c closely matches what the hardware can do <OriansJ>braunr: There are other thin layers that do a better job like Fortran, PL/m, Oberon, etc <braunr>if you don't like c, you don't like the hardware <braunr>ZombieChicken: which is why people are moving to java and c# <braunr>i know fortran evolved a lot since 77 <braunr>but i didn't bother with the new stuff <braunr>i'd suggest ada over it any time <braunr>maybe, but i'm not sure about the hardware of such a lisp machine <ZombieChicken>Came to the realization that my desktop is utterly broken this morning <OriansJ>braunr: PL/M was always much better for writing low level software. Lisp was better for high level and dozens of others have better fits all over the place but C was the one which was made by Unix. <ZombieChicken>Never a good sign when I run a command and it fails, then rerun it instantly afterwards and it works fine <braunr>OriansJ: i don't know pl/m enough to agree on that <braunr>but i don't see how you could write a better glue than c honestly <ZombieChicken>Update the standard library to offer secure options, implement a reasonable garbage collector... <OriansJ>braunr: that is because Unix made it the Glue <braunr>ZombieChicken: you don't want "security" to stand in the way <braunr>OriansJ: notwithstanding that, show me what would make a better glue <braunr>slyfox: the hardware doesn't know what a "string" is <braunr>actually x86 does, but x86 strings are just vectors <slyfox>c is quite far from nowaday's hardware <braunr>ZombieChicken: but c-style strings <braunr>i think slyfox wants true strings <OriansJ>braunr: Not withstanding x86 has string support. <braunr>18:07 < braunr> actually x86 does, but x86 strings are just vectors <ZombieChicken>I seem to recall some arch from Way Back When that could read a plaintext file and execute it. It never went anywhere because it was SLOW, but still <braunr>x86 is like java/c#, it makes mistakes less likely <braunr>but unlike java and c#, it's the fastest thing around <OriansJ>braunr: Hand tuned assembly always wins <braunr>for most cases he could die before finishing <braunr>compilers are amazingly good nowadays <OriansJ>braunr: Take the best assembly made by the best C compiler, it can be hand tuned by knowledge that the compiler can't have. <braunr>OriansJ: but you can give the compiler than knowledge <ZombieChicken>I would like to point out that JIT can outrun precompiled in some cases <braunr>mtune is about the specific target <slyfox>C (or a platform it runs on) has it's own random semantics that hinder optimisations <braunr>2/ they're specifically aimed at performanced <OriansJ>braunr: not always, lithographic imperfections is a great example <braunr>which is why c code can get so buggy <slyfox>-fsemantic-interposition is a recent addition to gcc <braunr>OriansJ: that would be specific to single processor right ? <OriansJ>braunr: that is where hand tuning makes sense. <ZombieChicken>AFK. gotta test this LiveUSB out and see if the noveua driver actually works for this system <braunr>and when does a single processor make sense ? <braunr>slyfox: taht's about runtime linking right ? <slyfox>this flag changes code generation <slyfox>it removes an indirection during function call to disable symbol interlosition with LD_PRELOAD or similar <OriansJ>braunr: Knowing the number of execution units is another example used in super computers all the time. <braunr>OriansJ: ok that's one case, i would still rather teach the compiler <braunr>slyfox: so that it doesn't need to expose some symbols ? <slyfox>so it could (say) inline "local" functions <slyfox>something that JITs do routinely <braunr>you're talking about an option here <OriansJ>braunr: VLIW has a very similar problem and ultimately no one has figured out how to implement that correctly. <slyfox>you said C is a thin layer on top of hardware <braunr>i don't see the point of your example <slyfox>when you call a function you don't see amount of indirections runtime has to go through <braunr>the very existence of the option proves it <slyfox>it's not C, but a random compiler's flag <OriansJ>braunr: When optimal performance is required, hand tuned assembly custom to the hardware being used is the only option. <braunr>then why use something that is not about c, as an argument against c ? <braunr>OriansJ: it may be in some cases <braunr>OriansJ: for current processors, it usually isn't <braunr>you gave a few very specific example <slyfox>it's an example where C does not provide enough control over things that happen in hardware <braunr>i could give you the code your machine is running right now as a counter example <braunr>slyfox: i have no idea what you mean <OriansJ>braunr: Most of the time, no one cares about a 5to 7% performance difference but when it matters, asm is usually embedded in C. <braunr>and i'll use linux as an example, where 1-2% performance increases are regularly measured for some patch series <braunr>and the patch usually consist entirely of c code <OriansJ>braunr: Linux has a shitload of hand tuned assembly <ZC-wuz-hur>How much of that assembly is simply legacy code? <braunr>much of it is historical, or target-specific <OriansJ>braunr: NO, it is what helped Linux Win performance <braunr>i don't know, it's too big for me <CharlieBrown>ZC-wuz-hur: Cool. I have three 16 GB flash drives: one for data, one for ISOs, one for an installed play system. <braunr>the performance-critical assembly is .e.g. memory barrier code, which is target-specific <braunr>sting/bit functions, again, target-specific <ZC-wuz-hur>CharlieBrown: What I did was run dd and copy the drive image to my hard drive, use qemu to install to the resulting .img, then dded it back onto the flashdrive <braunr>and the rest is of course system management instructions, not the role of the compiler <braunr>what helped linux win performance is its dcache <OriansJ>braunr: target-specific is where performance is critical <braunr>or rcu and its lockless page cache <braunr>OriansJ: no you don't understand <braunr>i mean that the compiler couldn't do it <ZC-wuz-hur>Hasn't linux almost always outperformed Windows? <ZC-wuz-hur>Fairly sure Linus won't use anything other than ANSI C <ZC-wuz-hur>Well, some GNU extentions, yeah. Only way to get assembly in the resulting binary <braunr>and some of his swearing is about standard c not having some gnu extensions <ZC-wuz-hur>braunr: Unless I'm mistaken, ANSI C has no way to embed assembly in it for those "performance-critical" internal loops and whatnot <OriansJ>braunr: llvm had to add GNU extensions to support linux <braunr>lots of compilers support many gnu extensions <braunr>c11 made it slightly better though <ZC-wuz-hur>CharlieBrown: Well, it's what I did. Do what works for you. I was just making a suggestion <braunr>i'll just say that, in order to really beat c, you need .. <ZC-wuz-hur>Nothing shows how dirty a monitor is like a BRIGHT WHITE terminal... <ZC-wuz-hur>Oh wow. I just installed extremetuxracer, and the symlink isn't in .guix-profile/bin/ ... <ZC-wuz-hur>apparently it's named "etr", not "extremetuxracer" <ZC-wuz-hur>Anyone have any suggestions for a good program to test 3D performance? <xkapastel>that's a simple 3d game that'll let you know if your stuff is working <ZC-wuz-hur>glxgears worked fine, and extremetuxracer worked <OriansJ>ZC-wuz-hur: just turn up warzone2100's settings <ZC-wuz-hur>I'm installing minetest, chromium-bsu, and warzone2100 atm <ZC-wuz-hur>If this works, I just need to figure out RAID and LUKS and I should be set <ZC-wuz-hur>and hopefully everything else I want to run with play nicely <CharlieBrown>I'm trying to put GuixSD on a multiboot ISO but the installer image is not an ISO and IDK how to extract it and look at the grub.cfg. <ZombieChicken>yay. apparently the open-source nVidia driver won't work for me <reepca>Regarding the build tool in the GSoC suggestions, it says "... should ultimately be able to run complex workflows on multiple servers..." - what exactly does that mean? That the build process should be able to be distributed across systems? <lfam>reepca: You might have better luck starting the discussion on the mailing list; the Guix developers interested in that project may not be on IRC right now <marusich>CharlieBrown, if you want to examine the grub.cfg which got generated for the installation image (which, as you correctly pointed out, is not an ISO-9669 file system image), one way you can do that is to mount the image as a loopback device, and then examine its file system like any other. <marusich>Where, of course, the exact device and directory to use in your mount invocation depends on what actually exists. <marusich>If you plan on using GuixSD in a multi-boot situation, you should be aware that changes which update the grub.cfg file might blow away any customizations you have made to accommodate the multi-boot setup. <marusich>(i.e., 'guix system reconfigure' and the like) <roelj>It seems that when I try to compile Guix with Guile 2.2, it cannot find the gnutls guile module.. Is this a known problem? <janneke>roelj: yes you need to install guile2.2-gnutls (or gnutls/guile-2.2) <kadintrooper>If I wanted to symlink python3 to python how would I go about that <lfam>kadintrooper: If you are asking about doing that within the context of Guix packaging, use the package python-wrapper <lfam>Or python-minimal-wrapper; it depends on what you need ***jonsger1 is now known as jonsger
