IRC channel logs

2014-08-09.log

back to list of logs

<dsmith-work>ijp: How fare has it progressed?
<dsmith-work>far
<ijp>dsmith-work: all that time was eval.go
<dsmith-work>That does sound too long.
<ijp>I'll try catching wingo again, and see what's changed in the bootstrap implementation that could cause it
<ijp>my guess would have be a stuck loop, since nothing on strace, and memory use was stable
<taylanub>wasn't one O(n^2) bug recently fixed? is compilation still slow?
<ijp>unless wingo hasn't pushed it, I'm completely up to date
<dsmith-work>ijp: Is the cpu cranking, or is it just idle?
<ijp>dsmith-work: full load
<taylanub>Imma try compiling master too overnight
<dsmith-work>ijp: Are you swapping?
<ijp>dsmith-work: what tooling would I be using to check that?
<dsmith-work>cat /proc/meminfo
<dsmith-work>top
<dsmith-work>I usually just glance at gkrellm
<dsmith-work>top is easier to read
<ijp>well, Id need to start it building again for meminfo, but as best as I could tell from top, memory use wasn't really changing
<dsmith-work>ijp: I was wondering if you ran out of ram, and so started swapping. Which would make compiling about 100x slower. (or however much slower disk is that ram)
<dsmith-work>ijp: Master does need a huge amount of memory.
<dsmith-work>ijp: Just built master on my 4-core system with make -j3
<dsmith-work>real 86m48.692s
<dsmith-work>user 203m47.624s
<dsmith-work>sys 0m32.638s
<paroneayea>hullo
<mark_weaver>hi
*paroneayea just installed geiser, going through http://classes.soe.ucsc.edu/cmps112/Spring03/languages/scheme/SchemeTutorialA.html and reading some of sly's code
<mark_weaver>I think that tutorial isn't really enough to give you an idea of programming in Scheme.
<mark_weaver>and sly uses some very advanced techniques. there's too much of a gap between those two things.
<paroneayea>mark_weaver: probably. I do know enough common lisp and emacs lisp, so I have a sense of what's going on, though yes, I don't know scheme!
<paroneayea>man, not saying it's guile's fault, but "srfi-26" is not a descriptive explaination of what's going on in that module
<mark_weaver>the SRFIs are numbered instead of named because anyone can create a SRFI and finalize it.
<mark_weaver>and often there are competing SRFIs that implement the same functionality.
<mark_weaver>the idea is to let the users decide which ones they like.
<paroneayea>that's a logical reason... it's still not clear though :)
<mark_weaver>true enough!
***karswell` is now known as karswell
<taylanub>What would be an idiomatic way to conditionally either parameterize something, or leave it default? thinking of (parameterize ((foo (if do-it? bar (foo)))) body) but it's not very nice
<nalaginrut>taylanub: I think you h
<nalaginrut>I think you have to decide the value of parameter in the last level
<taylanub>for now I decided to put the body in a proc and do (if change-param? (parameterize ((param foo)) (do-it)) (do-it))
***Wasmachine is now known as optimus_swine
<paroneayea>returning to me blathering about a javascript compilation target, I think what would be pretty/more exciting would be one that compiles to asm.js
<taylanub>paroneayea: that's what emscripten does, no?
<paroneayea>taylanub: yup
<taylanub>given emscripten isn't GNU software, I wonder if Guile would "officially" adopt it...
<taylanub>probably not. maybe we can target ASM.js directly
<paroneayea>taylanub: well I'm not thinking of using emscripten
<paroneayea>probably you could already port guile to javascript using emscripten but it wouldn't be ideal and you'd be hosting the whole guile infrastructure in the browser
<mark_weaver>the most tedious part of porting guile to target any non-C target will be all of the library procedures that are currently implemented in C.
<paroneayea>but targeting to asm.js, yes
<paroneayea>mark_weaver: has anyone done any compilation to a non-C language yet? I'm assuming not for that reason
<mark_weaver>no
<mark_weaver>however, we are gradually reducing the amount of C code in Guile and replacing it with Scheme code.
<taylanub>might be useful looking into Spock, Chicken's to-JS interpreter/compiler
<mark_weaver>for a long time we were almost 100% C, and now we have more Scheme code than C.
<paroneayea>maybe the C parts could be compiled to asm.js using emscripten, then a asm.js compilation target could also be built ;) (/me has no idea how feasible that is, probably not easy)
<paroneayea>also, I've never looked at what on earth emscripten produces and what "linking" to it is like, so :)
<mark_weaver>well, the other thing is garbage collection. we currently rely on Boehm GC to do garbage collection.
<mark_weaver>I don't know off-hand whether programs compiled by emscripten will do GC properly.
<mark_weaver>it's an interesting idea though!
<taylanub>emscripten already supports a GC with a "Boehm-like" API it seems
<mark_weaver>ah, nice
<paroneayea>mark_weaver: I would think it could do that; there are a lot of crazy C applications I've seen ported to the browser through emscripten
<paroneayea>it's proprietary, so I'm not advocating it! but the "unreal engine ported to firefox" thing that mozilla posted was a pretty good example. Iirc that engine has its own scripting language also, which surely has its own memory allocation techniques
<mark_weaver>what's proprietary?
<paroneayea>the unreal engine
<paroneayea>a proprietary game engine
<paroneayea> https://blog.mozilla.org/blog/2014/03/12/mozilla-and-epic-preview-unreal-engine-4-running-in-firefox/
<paroneayea>but it's a big, complicated piece of technology
<mark_weaver>oh, I see
<paroneayea>also, python has been ported to the browser also via emscripten (it takes a while to load though, since it loads all of python...)
<mark_weaver>well, it would be an interesting experiment, I suppose.
<mark_weaver>I don't think it's the best approach in the long term though.
<paroneayea>I'm not advocating that the guile VM actually run in the browser as the guile VM though... would be more interesting if a compilation target that's more self-aware than that
<mark_weaver>I suspect a better approach for us to officially support would be to reduce the amount of library C code in Guile to almost zero, and then to compile to javascript directly.
*paroneayea nods
<paroneayea>that makes sense to me
<mark_weaver>most people who want to write a web site are not going to want to have to serve up a huge hunk of compiled-from-C code that uses a huge amount of memory and network bandwidth.
<paroneayea>I agree :)
<mark_weaver>:)
*mark_weaver goes offline for a bit to boot into a new kernel...
<nalaginrut>to reduce C part to zero? well, is it possible to write the whole VM with Scheme?
<paroneayea>nalaginrut: pypy? ;)
<mark_weaver>I said "almost zero" :)
<nalaginrut>yes, pypy is excited ;-)
<mark_weaver>although scheme48 wrote their VM in a subset of Scheme.
<nalaginrut>mark_weaver: well, it's excited too! ;-)
<mark_weaver>anyway, time for me to reboot...
<nalaginrut>see you guys
<paroneayea>PyPy is a really neat project
<nalaginrut>I've to go to bed
<paroneayea>later
<mark_weaver>nalaginrut: sleep well!
<nalaginrut>night ;)
<taylanub>nalaginrut: I think you mean "exciting" :)
<zacts>mark_weaver: hey, http://www.optalysys.com/technical-faqs/
<zacts>I feel like C is going to possibly be a thing of the past..
<ijp>yeah, people were saying that in the 80s
<ft>:)
<optimus_swine>C, or something like C, will always be relevant, I just hope it'll be a thing of the past for applications where it was never intended for.
<optimus_swine>C is pretty grossly overused for stuff you absolutely don't need the speed of C for but the amount of bugs C code tends to have are less than wanted.
<optimus_swine>zacts, also
<ijp>so, C would go away fro everything except for writing unix alikes?
<zacts>optimus_swine: your nick reminds me of transformers Optimus Prime.
<optimus_swine>Did you know that PC gamers are genetically superior to console gamers.
<optimus_swine>zacts, wel, it's a reference yes
<optimus_swine>On abother server I am optimus_gaynigger, but I felt that that nickname would get me banned of 60% of freenode channels.
<optimus_swine>So I choose something more politically convenient.
<ijp>for obvious reasons
<optimus_swine>Still, The Gayniggers from Outer Space was an interesting film.
<optimus_swine>ijp, well, there are probably other low level stuff to write C in, but C was never really intended to write anything else than stuff that is very close to the metal.
<optimus_swine>mfw when people think C does not have things like inner functions or a sensible type system and array bounds because it's "old" while tonnes of languages before it had it already.
<taylanub>yesterday a ~40 year-old coworker was telling me how much he loves JS for being able to do something like var counter = (function(){ var count = 0; return function(){ return ++counter; }; })();, and if I saw it right he showed me a piece of code where he actually used this or something like it in practice, calling that usage pattern "immediately called function". no disrespect meant to him at
<taylanub>all, but it was an ironic situation of course
<optimus_swine>taylanub, well, in all fairness, rms' praise on lisp seems to mostly stem from dynamic typing.
<optimus_swine>All he wrote about why lisp is awesome is basically found in every other dynically typed language.
<mark_weaver>that's not true at all
<optimus_swine>Well, all I've seen from his praise on it seems to come down to the flexibility of heterogenous data structures, I've never seem him praise anythinhg in lisp that's not also in say python
<optimus_swine>I've yet to see him talk about hygienic macros or continuations and TCO but maybe he has at some point
<mark_weaver>"I skimmed documentation of Python after people told me it was fundamentally similar to Lisp. My conclusion is that that is not so. `read', `eval', and `print' are all missing in Python." https://stallman.org/stallman-computing.html
<ijp>and `quote'
<optimus_swine>Python has a REPL, if that's what he means.
<optimus_swine>Python is fairly similar to common lisp in a lot of ways though.
<taylanub>optimus_swine: no, I think he means the simplicity of transferring native data from one process to another, or storing it on disk
<optimus_swine>Ahh
<optimus_swine>As in write in scheme.
<optimus_swine>well, python also has serialization modules.
<ijp>not the same
<optimus_swine>You can fairly easily write a list out in python.
<taylanub>well actually I'm not sure now, since I realize he also mentioned eval
<ijp>but whatever, I've already gotten into two draining conversations for one day
<optimus_swine>I haven't yet, taylanub, if you do the honours with me?
<optimus_swine>Shall we have tihs dance.
<optimus_swine>Or wait, mark_weaver wrote that, not you.
<taylanub>optimus_swine: I was just referring to the above quote
<optimus_swine>taylanub, well yes, that'sthe same reason I thought it was about a repl.
<optimus_swine>Read, eval and print in one sentence typically refers to a REPL, which python also has.
<optimus_swine>IT's just inconvenient because whitespace sensitive and a strict distinction of expressions and statements
<optimus_swine>I never got that idea, I certainly get that if x = 3: where == is intedned is a common coding error, but why not use say <- for = then.
<taylanub>anyway, while rms is a respected computer scientist too, he has mostly been concerning himself with politics for a long time now if I'm not mistaken, so discussing this much over some short remarks he made seems pointless
<mark_weaver>I know RMS rather well, and I think he's talking about the fact that in lisp and scheme, code is trivial, easy-to-manipulate data.
<mark_weaver>of course, in any language it's possible to represent the code as data and read it, evaluate it, and print it, but it's vastly easier and more natural in lisps.
<optimus_swine>Truth be told, it's not exactly clear what he means with that, it could be either.
<optimus_swine>If I was talking about homo-iconicity, I would've dropped that term and just said "Python is not homo-iconic" to leave no confusion.
<mark_weaver>but I really don't have the time or interest to get into a debate about whether lisp has any advantages over python.
<optimus_swine>I never talked about whther ir had advantages or not. Obviously both have advantages over the other. I'm just saying that most I read about rms praising lisp seemed to be about heterogenous data structures.
<mark_weaver>on your first two sentences: fair enough. on the last, I think you have a limited picture of his opinions on the matter.
<mark_weaver>maybe that's because he doesn't talk about it much.
<optimus_swine>Could be, I'm of course only able to talk about what he said about it, which admittedly isn t much.
<mark_weaver>I've known RMS for a long time. For a few years, I spent most of my time two doors down from him at the MIT AI lab. I was the FSF staff sysadmin for a while, and did sysadmin work on RMS's laptop. I was his preferred typist when he shattered his elbow and helped him replace his bandages, etc.
<optimus_swine>But the heterogenous data structures seem to be a recurring theme.
<optimus_swine>Well, what in your opinion is his love for lisp stemming from then?
<optimus_swine>"Unlike most languages today, which require defining specialized data types, Lisp provides a few data types which are general. Instead of defining types, you build structures from these types. Thus, rather than offering a way to define a list-of-this type and a list-of-that type, Lisp has one type of lists which can hold any sort of data." this is hardly unique to lisp for instance, this is a common thing of dynically typed, or even static par
<optimus_swine>ametrically polymorphic languages.
<mark_weaver>that's true, other languages have gradually picked up various aspects of lisp over time.
<optimus_swine>Hmm
<optimus_swine>didn't lisp more or less pioneer dynamic typing at a time where other languages, id est fortran had no semblance of a type system?
<optimus_swine>This was the time of hollerith constants right?
<ijp>fortran had two types
<ijp>and dynamic typing has been around as long as computers have
<optimus_swine>That would be less than pair, symbol, nil and number
<ijp>in assembly, all you have are words
<optimus_swine>Well, I mean dynamic typing as in storing the type in some tag and barfing if the type was wrong at runtime.
<optimus_swine>I guess as far as type theory is concerned both are basically just unityped.
<mark_weaver>from the point of view of static typing, a dynamic type system seems unityped, but I think that's quite a distortion.
<mark_weaver>it's more fair to say that in a dynamically typed system, types are associated with values instead of with variables.
<optimus_swine>Well, in parametrically typed static languages it's hard to argue that variables have a type as well.
<optimus_swine>The issue I guess is that a "type error" in a dynamically typed language is basically a side effect.
<mark_weaver>it could also be thought of as an invocation of an exception continuation that's part of the dynamic environment.
<mark_weaver>and the dynamic environment can be thought of as an implicit argument that is passed down from callers to callees.
<mark_weaver>I'm not sure it's accurate to think of it as a side effect, because no state needs to be mutated.
<optimus_swine>Well, every side effect can be modelled as an extra argument passed down to every function
<optimus_swine>as in passing the state of the world around.
<mark_weaver>anyway, I don't really feel qualified to try to summarize RMS's opinion on these matters, and I'm not even sure it's relevant because he hasn't focused on programming in a long time. however, I do feel qualified to say that it's an oversimplication to think that dynamic-typing is the only important advantage he sees to lisp. I can say that much.
<mark_weaver>I'm aware that side effects can be modelled that way, e.g. in Haskell, but exceptions really aren't anything like a side effect. there's no state being changed.
<ijp>partiality rather than a side effect
*mark_weaver goes afk for a while
<zacts>"in assembly, all you have are words." - sounds like a poem..
<optimus_swine>mark_weaver, well, what if the side effect is priting "error, wrong arguments to apply" on the standard error port and exiting the program.