IRC channel logs
2016-12-12.log
back to list of logs
<nalaginrut>wingo: I've testing the server core, but after some C-c or C-d from client side for breaking the connection randomly, the (fdes->ports listen-fd) returned () then cause an exception. Do you have any idea bout it? <nalaginrut>well, seems the listen-socket was recycled by GC since I didn't reference it directly, but using its file descriptor <wingo>davexunit: yeah currently the compiler doesn't support unboxed float comparisons. a to-do item :) <wingo>unfortunately it requires 5 new vm ops because floating-point arithmetic is not commutative; oh well :P <wingo>ACTION updated fibers to make one dynamic state per fiber <wingo>perf results still ok (spawning 1M fibers, each of which writing one message to the same channel, then reading off all messages) takes around 7s instead of 6s <wingo>though it's a bit variable due to gc <davexunit>wingo: would they be tricky to implement? I could attempt the hack if it doesn't require toooo much experience with the compiler. <davexunit>it would *really* help because as of right now I can't do any real-time simulation without the GC running constantly and killing the frame rate. <wingo>davexunit: it's annoying but not tricky <wingo>well, not very tricky anyway <wingo>there is a template in the br-if-u64-<-scm instructions <davexunit>but besides this problem I think I've written a good test case that does no allocation. on my core i5 laptop using intel graphics I can render ~11,000 sprites at 60 frames per second. I should be able to animate them and keep the same frame rate once floating point comparisons are possible. <dsmith>{appropriate time} Greetings, Guilers <paroneayea>but "Unrewindable partial continuation" is probably the hardest thing to debug :) <davexunit>ACTION descends back into the bytecode swamps <paroneayea>I fixed the unrewindable continuation situation with a kludge <paroneayea>nothing like tracking down errors in your error handling code. <wingo>paroneayea: i am working on making those situations have better errors <wingo>in fibers to make an error if we abort but we know that we want to make a resumable continuation <wingo>paroneayea: you might be interested in recent push to fibers btw <wingo>has some docs in this regard <davexunit>if I can get that to happen without running the gc every <1 second I will be a happy camper <davexunit>5000 gems here. renders at 60 FPS but with stutters due to GC. <wingo>10000 cycles/gem/frame then? on a 3 GHz machine anyway <wingo>i guess first step is like you say to avoid boxed numbers <wingo>then golf it down from there <davexunit>if I remove animation the GC almost never runs <davexunit>if I keep moving sprites by their velocity but remove the bounds check that bounces them off the window borders, the GC almost never runs <davexunit>with the bounds check in place there is tons of GC <wingo>note that abs, div, min, max -- these things are easier to implement in a way than general fp comparisons <wingo>but i reckon we need div comparisons anyway <wingo>just not f64-<-scm kind of comparisons <davexunit>my use-case right now is doing <, <=, >, >=, = comparisons with unboxed floats <davexunit>I'll see if I can monkey type a solution based on the u64 stuff <davexunit>ACTION wonders about that JIT someone wrote for guile <davexunit>I think I tried to compile it awhile back and couldn't do it. I'd love to try it, but better yet I hope something like this can make it upstream. I would expect it to make real-time applications run more efficiently. <kyamashita>Is there an undocumented way to build Guile 2.1.5 faster? <paroneayea>kyamashita: ISTR I asked about this recently, and the bootstrapping part is the slowest, and I *think* you can point at another bootstrapped guile for it, but I don't remember how. <kyamashita>I have a low-resource machine that may take days (or weeks!) to build Guile. <wingo>usually it should pick up .go files from prebuilt/ <wingo>then can you try a thing plz <wingo>in your guile-2.1.5 tarball checkout <wingo>ln -s your-config-guess mips-unknown-linux-gnu <wingo>you need your exact config.guess value <wingo>guile .go files currently depend on endianness and word size but nothing else <wingo>so we will just need to record your endianness/word size via a symlink to an architecture with the same characteristics <davexunit>wingo: should I see "BOOTSTRAP GUILEC" lines if the prebuilt compiler is being used? <wingo>someone needs to write this up in a more practical way <wingo>i tried to write it up but it seems it's at too high a level :P <wingo>"how is it done in general" vs "how to know when it's going wrong" <wingo>paroneayea: just pushed one more code thing you might like <paroneayea>wingo: I also like that it contains a mini TODO list of "continuation barriers to remove" ;) <paroneayea>callbacks from some srfi-1 functions, that's surprising <wingo>there was a time when guile was rewriting things in c :P <paroneayea>I considerably simplified the message handling code in 8sync's actors subsystem today. <dsmith>wingo: Since there are only 4 kinds of go files, can ALL of them be made for the release tarballs? <paroneayea>a lot has changed in 8sync over the last week since I did the last release <dsmith>wingo: Or is that already happening? <paroneayea>maybe 0.3 will finally be a release with documentation, that maybe even someone would want to use ;) <wingo>i think i don't have a big-endian 64-bit system <wingo>yet? but maybe there are none <wingo>otherwise we have x64, ia32, mips <wingo>which should cover things? just missing config.guess symlinks <wingo>i should make the build print out more things for when the build knows that things will go slowly <kyamashita>wingo: For the record, my config.guess was powerpc-unknown-linux-gnu. <wingo>kyamashita: then "cd prebuilt; ln -s powerpc-unknown-linux-gnu mips-unknown-linux-gnu" i think <wingo>and try "make" and see if it goes any faster <paroneayea>wingo: wow, that last fibers commit is interesting. <paroneayea>pretty cool to be able to detect whether or not something is supendable <paroneayea>wingo: how long has that feature been around and I didn't know about it? :) <wingo>paroneayea: i just implemented it 10 minutes ago :) <paroneayea>I wonder if I still have that bug where I'm accidentally tacking onto the stack every time I yield in the actor model subsystem ;) <paroneayea>I discovered this by a character that runs in a loop in the game and frets every now and then, and I left the game on for a few days, and stack limit reached :) <paroneayea>I think it's because I parameterized on every re-entry or something stupid on my part. <kyamashita>"Stop fretting! You're going to make us hit the stack limit!" <wingo>so in that particular case interestingly you can just set the parameter instead of parameterizing <wingo>if you start each actor with its own dynamic state <wingo>i.e. instead of starting with thunk <paroneayea>wingo: hm interesting, that's probably the right approach <wingo>you start with (lambda () (with-dynamic-state parent-state thunk)) <wingo>but if the parameter is specific to the actor and not the "turn" of the actor then you can parameterize once, when you run the thunk the first time <wingo>(lambda () (with-dynamic-state captured-state (lambda () (parameterize ((foo bar)) (thunk))))) <wingo>assuming the with-dynamic-state is useful to you <wingo>otherwise you get weird effects if one actor sets a parameter, it is seen by other parameters <wingo>also you probably want actors to inherit dynamic states <wingo>like from the actors that create them <paroneayea>the actors generally don't share state... shared nothing environment <wingo>but you probably want to be able to (parameterize ((current-error-port ...)) (spawn my-actor)) <paroneayea>probably true. The "real" actor response would be, well you just have one actor manage the error message port ;) <paroneayea>but I'm not necessarily sure to be totally pure. <wingo>i should add a #:preemptive? flag to run-fibers <paroneayea>wingo: I'll be very interested to see how that works out :) <wingo>paroneayea: did you look at asyncs.test? :) <wingo>something very similar i think <paroneayea>wingo: I did, but not long enough to fully grok it yet. <wingo>except if suspendable-continuation? returns false, then just pass <wingo>maybe i can get that done now... <paroneayea>wingo: I feel like there has to be a lot of gotchas to the pre-emptive stuff I'd blow myself up on <wingo>lots of application-level gotchas i think <wingo>but from a framework pov, all good <wingo>like i think you can make a pretty solid preemptive fibers without too much work actually <wingo>whether users will be able to program it is another question :P <wingo>users including myself of course <wingo>anyway it's a nice feature for people that want it <random-nick>wingo: AFAIK IBM's POWER8 is 64 bit and has both big and little endian modes, so there is a 64bit big endian machine <paroneayea>I'm trying to make 8sync fairly goof-proof, especially because I'm the biggest goof I know <paroneayea>so if I can make it so the underlying system handles can guide things so you don't blow yourself up on a pre-emption landmine <wingo>random-nick: yeah i wonder tho which mode is normal <wingo>64-bit big-endian definitely does exist like you say <wingo>but i don't know if it even meets the very low threshold for "guile should support this" <random-nick>afaik the only usecase for 64bit big endian is backwards compatibility <janneke>ACTION just released Mes 0.3 -- first actual release <kyamashita>wingo: I get a segmentation fault when generating guile-procedures.texi. <kyamashita>It goes away when I delete the symlink in prebuilt/ <wingo>kyamashita: ah, then perhaps i pointed you to an incompatible prebuilt/ :/ <janneke>to move forward i really needed a garbage collector...getting that integrated and the last bugs out took me about 6 weeks <wingo>for me those files are indeed big endian <wingo>but perhaps we have a problem with our big endian compiled files since they are rarely tested... possible i guess <wingo>mark_weaver: you run mips32 in little-endian mode, right? <kyamashita>The "file" command does indeed report them as big endian. <wingo>kyamashita: i assume you got past the guile-procedures.texi stage previously, right? <wingo>kyamashita: were you able to compile bootstrap/ice-9/eval.go? <wingo>kyamashita: and also the next file, or no? did it sit waiting forever <wingo>the build process speeds up as it goes fwiw <wingo>it's not time for first file * number of files <kyamashita>It sat waiting "forever" (over 3 days, in reality). Then I came here to see if a faster solution was possible. <wingo>it could be that our big-endian compilation is busted <wingo>that would be my fault if so :P <wingo>is there any way for me to have access to a big-endian machine? better if it is powerful of course <kyamashita>wingo: We'll see. I can leave the process running for a few weeks or months if necessary (building on a Wii with copious swap space, for reference). <wingo>kyamashita: ok, it shouldn't have to be like that tho! <kyamashita>paroneayea: Yup. I have nothing to lose, as it's fully proprietary otherwise. <kyamashita>paroneayea: A highly integrated Linux<-->Guile setup is what I'm hoping for. <wingo>would be nice if i could clock_nanosleep() from guile, then i could spawn a thread to sleep in terms of cpu time rather than real time <kyamashita>paroneayea: I have a root partition backed up for it if anything goes wrong. <paroneayea>kyamashita: did you use the twilight princess hack to get root access? <kyamashita>paroneayea: I used the bannerbomb hack, I think it's called. <davexunit>one of my coworkers has some hacked wiis that he runs an old version of debian for powerpc on <kyamashita>paroneayea: I then installed Priiloader, took armboot.bin from the MINI project and supplied the Linux kernel on an sdcard FAT partition as a PowerPC binary. <kyamashita>davexunit: I bootstrapped up to Linux From Scratch 7.9. <davexunit>then you ought to be able to port guixsd to it ;) <kyamashita>The only problem is the kernel. I'm stuck on Linux-libre version 2.6.32. <kyamashita>I don't know if I have the skill to forward port the patches. <kyamashita>It does, but upstream Linux support for the Wii is limited. The gc-linux project was getting things submitted upstream, but they've stopped for whatever reason. <kyamashita>A vanilla kernel doesn't even give you a framebuffer to see what's going on. <davexunit>I imagine the effort needed to keep linux working on an obscure platform like that is great <kyamashita>Definitely. There were many regressions in upgrading to the 2.6.33 kernel. I think progress mostly stopped there. Someone else tried to keep the patches going, but their kernels didn't work for me. <kyamashita>davexunit: What is GNU Shepherd's minimum kernel version requirement, if there is one? <davexunit>I don't think it uses any linux-specific features <kyamashita>I'll see about setting that up if Guile builds successfully then. <davexunit>it can easily tested without having to make it pid 1 <kyamashita>Really? I'll have to learn more about how it works. <davexunit>it really just manages daemon. I run a shepherd instance as my unprivileged user to manage things like emacs --daemon <davexunit>you can give it the privileged position of being pid 1 or not, it's all good. :) <kyamashita>Cool! I also have a Hurd box that I hack on. It'd be wonderful to get GuixSD running on the Hurd. Debian sid makes me nervous. <paroneayea>speaking of concurrency, the concurrency branch in emacs landed. I'm kind of nervous about it though <paroneayea>no good abstraction around the pile of locks and etc <paroneayea>I'm really worried we're going to see a lot of deadlock code hit emacs soon. <paroneayea>that's a biased post, but one that shares my bias <davexunit>wouldn't better async i/o be the first thing to do? <davexunit>now guile-emacs will have to be compatible with however this thing works <kyamashita>Isn't guile-emacs fairly complete? I know it can't run Emacs Lisp bytecode yet... <davexunit>it works, but big changes like this concurrency thing are going to be a problem <davexunit>people generally haven't supported guile-emacs <galex-713>there were big propaganda saying guile-emacs was a plan to kill elisp by replacing it with scheme too <galex-713>That’s terrible because actually beside that I’ve only heard really good stuff from the potential of a guile-emacs :/ <kyamashita>IIRC guile-emacs is just emacs with the current emacs lisp VM replaced with the guile VM, yes? <davexunit>use guile's compiler and VM instead of what emacs has <paroneayea>anyway, yeah, I'm not sure how the concurrency branch can mesh with it <paroneayea>and probably between the this code and the portable dumper code <paroneayea>a lot has changed that has brought the guile-emacs branch pretty out of date <paroneayea>the portable dumper code probably is just a difficult merge, but yeah, the GIL approach is the more challenging part. <galex-713>there are also all these drawbacks to solve that makes guile-emacs super slow and basically unusable <paroneayea>galex-713: it's basically incomplete, unoptimized code <galex-713>the stuff with dynamic scope, buffer-local variables, etc. <galex-713>+ the problem that guile is still horrifically slow to compile because no bootstrap nor native-compilation, and that the core will be bytecode instead of natively compiled code <paroneayea>galex-713: well, there's a good chance that natively compiled code will come to Guile soon. <galex-713>dreaming in my sleep of a hypothetical future day where guile would be able to have all the nice ocaml stuff but being lisp/scheme <paroneayea>galex-713: well, soon as in, I'm not sure when it'll hit Guile proper. but someone wrote a fork of Guile that includes a JIT compiling to native code, and there's talk on the mailing list from a couple of months ago about how that could be done using hooks. <paroneayea>galex-713: check the mailing lists for some details on that. <dsmith>galex-713: "soon" is relative. ;^) <galex-713>yeah but yet it’s “soon”er than when wingo mentioned it on his blog <ArneBab>galex-713: guile-emacs takes a really long time to start because it is lacking polish, not because of a fundamental problem. <ArneBab>except for the fundamental problem that there are too few people with too little time compared to the huge number of important tasks which all need lots of time :) <terpri>guile-emacs's slow loading is mainly because guile doesn't know how to serialize elisp strings (and some other types), so it has to load everything from source <galex-713>the good’ol problem of “people with time lack skills and people with skills lack time” <wingo>paroneayea: just pushed support for preemption <wingo>terpri: i guess we should fix that <wingo>terpri: if you want to braindump to bug-guile@gnu.org, that might be a useful thing; dunno <paroneayea>I agree, would be nice to see a braindump to bug-guile <terpri>wingo, i'll take a look and see if i can remember what the problem was <wingo>things happen by hackers hacking and it is a slow process, and when we win, it's just by showing up over time :) <wingo>i know it's fun to speculate about these things but sometimes the speculation causes unwanted pressure :) <wingo>there's also a weird thing about tech, where new things come out a lot over time and it has this really weird anxiety-inducing effect <wingo>like "what's guile's AWS lambda compute-at-the-edge internet-of-things story, OMG we're doomed" sort of thing <wingo>can make you feel like anything that wasn't created in the last 3 years isn't viable <ArneBab>galex-713: do you know that people run the hurd on metal nowadays and that there is already support for running subhurds as a plain user? <ArneBab>so "end up like the Hurd" still exists as a proverb, but it’s been deprecated by reality :) <ArneBab>(or rather: by a handful of hackers who kept hacking despite all the mockery) <ArneBab>(and kept doing what they knew was right — or at least exciting and/or challenging) <ArneBab>"GNU Hurd 0.8, GNU Mach 1.7, GNU MIG 1.7 released" <kyamashita>ArneBab: I use it daily, and GuixSD gets closer to fully supporting the Hurd every year. <ArneBab>kyamashita: I used to run the Hurd (and write the Month of the Hurd) before I moved my efforts to supporting Freenet. And it is great to see the Hurd move forward! <galex-713>Hurd still doesn’t support USB, sound, wifi, and most architectures, and it only began to support SATA and 64bits <galex-713>I do know some hurd devs (like youpi) so I know it is usable, I also know it has this same very problem of “people with enough skills don’t have time, people with time don’t have skills” <galex-713>actually it really need to achieve that glue code that allows to compile linux modules for hurd first… <galex-713>at least for wifi, and maybe usb, sound and graphics if possible <galex-713>is dde the correct name for the “glue code” thing I heard? <ArneBab>it can already provide support for some network cards