IRC channel 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

<nalaginrut>maybe an exception from experience

<nalaginrut>ACTION noted it

<wingo>good morning guilers

<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

<ArneBab>moin wingo

<wingo>good morning ArneBab

<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

<wingo>and memory usage is similar

<wingo>so, all good i think

<ArneBab>nice!

<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>cool

<davexunit>I will try to take a look then

<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

<OrangeShark>hello everyone

<davexunit>hey OrangeShark

<OrangeShark>how are you davexunit?

<davexunit>doing well. how are you?

<OrangeShark>I am doing alright

<davexunit>good :)

<paroneayea>delimited continuations are so cool

<paroneayea>but "Unrewindable partial continuation" is probably the hardest thing to debug :)

<davexunit>surprisingly, I've never encountered that

<davexunit>ACTION descends back into the bytecode swamps

<paroneayea>whew

<paroneayea>I fixed the unrewindable continuation situation with a kludge

<paroneayea>8sync actors are pleasant to debug again.

<paroneayea>nothing like tracking down errors in your error handling code.

<davexunit>:)

<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

<davexunit>if i use my gl rendering code with a cute sprite sheet I can make stuff like this collage of gems http://i.imgur.com/JzwwWyn.png

<wingo>paroneayea: you might be interested in recent push to fibers btw

<wingo>has some docs in this regard

<wingo>davexunit: cool :-)

<davexunit>animated (massive gif warning) http://i.imgur.com/ni27jAz.gif

<davexunit>if I can get that to happen without running the gc every <1 second I will be a happy camper

<holomorph>o.O

<davexunit>;)

<davexunit>it's a nice little stress test

<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>it's all boxing as far as I can tell

<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

<davexunit>due to br-if-< and co.

<wingo>note that abs, div, min, max -- these things are easier to implement in a way than general fp comparisons

<wingo>s/div/mod i meant

<wingo>but i reckon we need div comparisons anyway

<wingo>just not f64-<-scm kind of comparisons

<wingo>i hope not anyway...

<davexunit>heh

<davexunit>my use-case right now is doing <, <=, >, >=, = comparisons with unboxed floats

<wingo>that is fine then

<wingo>that will work well

<davexunit>cool

<davexunit>I'll see if I can monkey type a solution based on the u64 stuff

<davexunit>thanks for the pointers (no pun intended)

<wingo>:)

<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.

<paroneayea>davexunit: yes

<paroneayea>that would be great

<paroneayea>wingo: oooh nice

<paroneayea>wingo: I'll look at the commit

<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.

<paroneayea>I could be wrong.

<paroneayea>maybe that's wishful remembering. ;)

<kyamashita>I have a low-resource machine that may take days (or weeks!) to build Guile.

<wingo>kyamashita: from a tarball

<wingo>does it not work for you?

<wingo>what platform are you on?

<wingo>usually it should pick up .go files from prebuilt/

<wingo>lmk your config.guess value

<kyamashita>PowerPC GNU/Linux.

<wingo>right!

<wingo>big endian, right?

<kyamashita>Yes.

<wingo>64 bit or 32?

<kyamashita>32 bit.

<wingo>then can you try a thing plz

<wingo>in your guile-2.1.5 tarball checkout

<wingo>cd prebuilt

<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>davexunit: yes

<davexunit>okay

<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

<paroneayea>wingo: the fibers continuation docs are good.

<wingo>"how is it done in general" vs "how to know when it's going wrong"

<wingo>paroneayea: tx!

<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" ;)

<wingo>hehe :)

<paroneayea>callbacks from some srfi-1 functions, that's surprising

<wingo>grep the code for scm_call_

<wingo>there was a time when guile was rewriting things in c :P

<paroneayea>;)

<paroneayea>I considerably simplified the message handling code in 8sync's actors subsystem today.

<paroneayea>mudsync seems to be working with it

<paroneayea>which is my usual testbed for robustness.

<wingo>nice

<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>dsmith: yep

<wingo>i think i don't have a big-endian 64-bit system

<wingo>yet? but maybe there are none

<wingo>in practice.

<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>I'm snarfing it! :)

<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 :)

<wingo>hence the shim

<kyamashita>lol

<paroneayea>:)

<paroneayea>speaking of dynamic foo

<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 :)

<wingo>exciting :)

<paroneayea>I think it's because I parameterized on every re-entry or something stupid on my part.

<paroneayea>fretted to death!

<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>like

<wingo>(lambda () (with-dynamic-state captured-state (lambda () (parameterize ((foo bar)) (thunk)))))

<wingo>assuming the with-dynamic-state is useful to you

<wingo>i think probably it is

<paroneayea>wingo: that sounds like it is

<paroneayea>I'm going to try it

<wingo>otherwise you get weird effects if one actor sets a parameter, it is seen by other parameters

<wingo>er

<wingo>by other actors

<paroneayea>right

<wingo>also you probably want actors to inherit dynamic states

<wingo>like from the actors that create them

<wingo>part of the same thing

<dsmith>wingo: Cool.

<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>hm.

<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>:)

<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

<paroneayea>but maybe I'm just over-worrying

<wingo>well yeah

<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

<paroneayea>I think it's a tantalizing direction to explore

<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

<paroneayea>then it'll be great :)

<paroneayea>that remains to be explored!

<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

<wingo>congrats janneke

<janneke>thanks!

<paroneayea>congrats janneke :)

<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>thanks paroneayea & wingo!

<wingo>kyamashita: odd tho

<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?

<kyamashita>wingo: Yes.

<wingo>kyamashita: were you able to compile bootstrap/ice-9/eval.go?

<kyamashita>wingo: Yes.

<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>zow

<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

<wingo>maybe a way through qemu?

<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).

<paroneayea>kyamashita: you're using a Wii? :) for what?

<wingo>kyamashita: ok, it shouldn't have to be like that tho!

<paroneayea>just as a spare machine?

<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: fun.

<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.

<paroneayea>fun.

<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: That's where I started from!

<davexunit>let's get GuixSD on it!

<kyamashita>davexunit: I bootstrapped up to Linux From Scratch 7.9.

<davexunit>cool!

<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.

<davexunit>oh does linux no longer support powerpc?

<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 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

<davexunit>can be*

<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>daemons*

<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.

<davexunit>:/

<kyamashita>nooooo

<davexunit>and some say guile-emacs is too risky...

<paroneayea> http://www.lunaryorn.com/posts/a-blast-from-the-past-the-tale-of-concurrency-in-emacs.html

<kyamashita>davexunit: ikr?

<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>ugh, they implemented GIL

<davexunit>will something like this doom guile-emacs?

<paroneayea>maybe

<paroneayea>it's probably a pretty huge internal change

<davexunit>now guile-emacs will have to be compatible with however this thing works

<davexunit>and implement a GIL

<kyamashita>Isn't guile-emacs fairly complete? I know it can't run Emacs Lisp bytecode yet...

<davexunit>it never will run elisp bytecode

<davexunit>it compiles emacs lisp into guile bytecode

<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

<kyamashita>davexunit, galex-713: I've noticed that 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>that's the idea

<davexunit>use guile's compiler and VM instead of what emacs has

<davexunit>and profit

<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>so I don't know what can be done about that.

<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: huh?

<paroneayea>galex-713: it's basically incomplete, unoptimized code

<paroneayea>that's the main problem.

<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>Oh realllllly!??? :DDDDDD

<galex-713>I’ve been waiting for it so looooong!

<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

<galex-713>(I seriously made a dream of it)

<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. ;^)

<paroneayea>yes :)

<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>ah

<galex-713>Anyway

<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>wingo: :)

<paroneayea>terpri: ah, that's useful to know :)

<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

<galex-713>So is guile-emacs going to reborn one day?

<galex-713>or will it end like the hurd?

<wingo>galex-713: chill plz :)

<galex-713>?

<wingo>things happen by hackers hacking and it is a slow process, and when we win, it's just by showing up over time :)

<paroneayea>+1 wingo

<wingo>i know it's fun to speculate about these things but sometimes the speculation causes unwanted pressure :)

<galex-713>oh yeah right

<galex-713>especially as I was putting it ><

<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

<paroneayea>internet of guiles

<wingo>dunno

<wingo>ok zzz

<wingo>night folks :)

<kyamashita>wingo: night! Thanks for the help.

<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>galex-713: see http://hurd.gnu.org ☺

<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>yay!

<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>ArneBab: yes I know

<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

<ArneBab>that’s because sound and USB are complex problem. DDE is the way forward for using Linux modules: http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=dde

<galex-713>is dde the correct name for the “glue code” thing I heard?

<ArneBab>yes

<ArneBab>it can already provide support for some network cards

<galex-713>cool

IRC channel logs

2016-12-12.log