<mid-kid>Okay, I think I've figured it out. Mes' execvp tries to search the file in $PATH because the path doesnt start with a leading '/'. <mid-kid>Making a makefile that tries to run a file with a shebang through an absolute path to the file seems to work. I'll try patching mes real quick. <mid-kid>Probably not the "proper" way to do this but it seems to work now. <oriansj>mid-kid: well the correct way to fix it would be to fix lib/mes/search-path.c's search_path but that would work as a work around <xentrac>oriansj: a cognitive preload requirement? <xentrac>two languages with very different philosophies from Scheme are Perl and C <xentrac>both were considerably more successful for a long time <xentrac>I think this is largely a result of their being more practical; Scheme was conceived as an exploration of the fundamentals of programming, while C was conceived as a more practical alternative to assembly <xentrac>I think probably Perl is less successful than Scheme right now <oriansj>both are considerably more successful than scheme if you look at metrics such as number of lines of code used in production, etc <oriansj>number of active developers is another critical metric <xentrac>well, Perl does have a lot of lines of code still used in production <xentrac>PHP has kind of taken over that area --- a programming language by and for non-programmers <oriansj>xentrac: I mean by preload as in the amount of the language you need to know before you can write a useful program. <xentrac>I think Racket is more popular now than in 2010 <xentrac>I don't think you need to know more to write a useful Scheme program than to write a useful C program; rather the contrary actually <xentrac>but I do think C syntax is more readable, and the basic concepts are more popular, so more people know them ahead of time <xentrac>like, to write useful C programs knowing Pascal or Fortran ahead of time, the amount you need to learn is very small indeed <xentrac>there are some things that are a lot easier to solve with the Scheme way of thinking though <oriansj>xentrac: true; although C generally has better introduction material readily available. <oriansj>aka, searching for how to do things in scheme tends to bring up dead-ends far more than successes <xentrac>there's better introductory material available because C has been more popular since the languages' births circa 1972 and 1976 I think <oriansj>xentrac: in the eyes of beginners not experienced programmers <xentrac>initially the introductory material available was just that produced by the relevant groups <xentrac>well, I suppose K&R is aimed at beginners, while the LtU papers are very much not <oriansj>even haskell has: Learn You a Haskell for Great Good <xentrac>but I think the crucial advantage was in C's adoption by experienced programmers, people like the BDS C guy <xentrac>C, being aimed at practicality, was useful on CP/M, while Scheme was not <oriansj>I'd argue its crucial advantage was its general availability of both good implementations but also good training material <xentrac>you could write a text editor in C in an afternoon; we've all done it <xentrac>if you did that in Scheme it wouldn't run reliably on a Z80 <xentrac>zork got rewritten for the z-machine to run on 8-bit computers <xentrac>but it was the kind of thing that scheme could enable you to imagine <xentrac>I agree that those were crucial advantages <oriansj>xentrac: I have a Jason Scott Interview that proves otherwise <xentrac>or even write an emulator for the z-machine <oriansj>but he interviewed the person who wrote the zork version for the PDP-11 which became the basis of zork for the personal computer <xentrac>the z-machine has a very different worldview from Scheme or Lisp <xentrac>specifically, it's designed in such a way as to have no implicit memory allocation <oriansj>xentrac: z-machine is just a sweet-16 way of dealing with bytecode <xentrac>actually no run-time memory allocation at all <oriansj>the byte-code itself is compiled from sources <xentrac>that is, not only doesn't it have a garbage collector, it doesn't even have reference counting or malloc/free <oriansj>xentrac: compiled Lisps don't have to require those things <oriansj>think of lisp code running though the eyes of a Fortran programmer <xentrac>if you can't use those things, what you're writing isn't Lisp, regardless of whether its syntax is written in S-expressions or not <xentrac>(and I don't know what the Infocom high-level language looked like; I think it's been lost) <oriansj>xentrac: it was a Lisp dialect called Model description language <dddddd>It's ZIL, and the sources of the games are available. <oriansj>it even includes old Lisp reader macros <xentrac>I think the Z-machine is super interesting because of the way it provides flexible data structures without any run-time memory allocation <xentrac>it's profoundly different from both the Lisp model and the C model <dddddd>My pleasure. I'm quite a bit into IF (; <oriansj>He is the guy behind getting old code running agai <xentrac>even the ZIL syntax is pretty far from Lisp, as it turns out <xentrac>(but pretty close to the syntax in the historicalsource/ repo) <dddddd>Inform 7 is kind of genius, but it's a double-edge sword in the sense that feels easier than it is. Also, localization feels weird (and not completely supported last time I checked). <xentrac>so the ZIL instructions for structuring data are <MOVE ,GLUE ,OUTPUT-HOPPER>, <LOC ,GLUE>, <REMOVE ,HORSE>, <FIRST? ,KITCHEN-CABINET>, and <NEXT? ,SEVERED-HEAD> <xentrac>according to this "Learning ZIL" book <xentrac>I can't figure out yet if ZIL had recursion <xentrac>(because it had to run on the Z-machine) <xentrac>the syntax is Lispier than I thought at first <xentrac>things it has in common with Lisp: prefix fully-parenthesized syntax (though using <>), symbols, COND, variadic functions. things it doesn't have in common: semantics, implicit variables (you need to use . or , in a way similar to $ in bash or Tcl) ***pgreco_ is now known as pgreco
***ChanServ sets mode: +o rekado
<jelle>is golang btw bootstrappable? <mid-kid>golang is probably the easiest. Build go 1.4, then build the latest. <oriansj>jelle: if you mean the language go; in the sorta there was a C package that could be built to bootstrap go sort of way, yes. Now does that source code look like it was written by a machine, yeah... *jelle is wondering if guix does this. I should probably take a closer look at the git repo :D <oriansj>jelle: So in effect yes and hence why go is in guix <oriansj>however looking at the C code, large chunks definitely do not match the sort of C code humans would write <oriansj>So it is the sort of we have a problem to deal with later but atleast we have a solid handle on it sort of thing. <oriansj>Basically a human could go and replace the generated bits by hand; solving that bootstrap sort of detail but it isn't a priority because other languages like Haskell and C don't even have that <stikonas>mid-kid, jelle: golang is bootstrappable with gcc directly, it builds with gccgo <stikonas>what's wrong with this approach? or am I missing something? <mid-kid>There isn't much wrong with that approach other than historically being restricted to newer gcc versions (older implemented go 1.3 iirc) <mid-kid>Also idk how compatible both implementations are, and the "official" implementation is committed to being buildable with go1.4 and they maintain sources to bootstrap it. <mid-kid>Is it normal for glibc 2.2.5's adjtime.c to take 2h to compile under gcc 2.95.3? <stikonas>by the way, are there any plans for non x86/amd64 bootstrap of gcc? I think tcc only supports those arches <stikonas>oh, maybe I'm wrong, tcc seems to have arm32 backend... ***warren_ is now known as warren
<oriansj>stikonas: the last I checked gccgo only supports up to 1.3 but one needs 1.4 to complete the current bootstrap chain. So there is that gap (Looking forward to when that is closed) <oriansj>also we have plans to extend MesCC to be able to build GCC directly, then we need only need ensure guile/mes-m2 runs on that platform. <oriansj>I also still need to take the time to do the stage0 steps for armv7l and aarch64 to enable those bootstraps in mescc-tools-seed; (armv7l support in M2-Planet is already done, dddddd is working on the aarch64 and it is in close to release state) <oriansj>mes-m2 is currently stuck because I have not been able to figure out a good set of tests for use-modules and define-module but alteast now 1+, 1- and guile records now work out of the box