IRC channel logs

2017-02-16.log

back to list of logs

***dsmith is now known as dsmith-work
<davexunit_>"Chez Scheme as the Racket VM" https://groups.google.com/forum/#!msg/racket-dev/2BV3ElyfF8Y/4RSd3XbECAAJ
<davexunit_>guile maintainer thoughts on this? :)
<paroneayea>davexunit_: I was just about to post that here :)
<paroneayea>yeah really interesting!
<davexunit_>my expectation is that we're interested in having our own compiler and VM
<davexunit_>but may steal a thing or two from Chez
<paroneayea>davexunit_: yeah, sounds right
<catonano_>davexunit_: wat could be "stealed" from Chez ?
<davexunit_>dunno exactly, but Chez dominates performance benchmarks
<davexunit_>so there's surely a few things that could be learned from it
<catonano_>I see
<avoine>one thing we could use is how they implement there vm using assembly to do native compilation: https://github.com/cisco/ChezScheme/blob/master/s/x86.ss
<avoine>wingo: mention it in his blog: "We need to lower the CPS even further, to get closer to some kind of machine model, then go specific, with an assembler for each architecture." https://wingolog.org/archives/2016/02/04/guile-compiler-tasks
<catonano_>avoine: thanks
<avoine>but maybe user friendlyness should be the next goal?
<avoine>like lines numbers in backtrace
<avoine>etc
<wingo>afaiu backtraces do have lines
<avoine>indeed, I miss understand the item #2 of your blog post "Wouldn't it be nice if the ELF files that Guile generates actually included the source as well as the line numbers?"
<daviid>heya! any successful attempt to run guile on a free mobile phone os?
<daviid>ACTION should ask that quiz on guile-user eally
<paroneayea>daviid: I'm sure you'd have no problem on an openmoko running debian ;)
<paroneayea>but yeah for phones that people use today, not sure, would be interesting to know
<daviid>paroneayea: i know next to nothing about phones, I use an old one, blocked dta transfer so it just allows phone calls and text msg (I wish I could hide the IP and block gps coordinates transfer to any one, even to the operator, but so far I could not :)
<daviid>this world is a mess
<paroneayea>tru dat
<daviid>we live in a very sad world, I feel terribly sorry for the kids...
<daviid>by the time they understand they have been manipulted, their entire life is in the hands of govs ...
<daviid>sorry! back to hacking, but I'm interested to get info from those of you guys who have a better knowledge about these mobile phones, os, and guile ... tx
<daviid>paroneayea: openmoko lastest nes is from 2012
<daviid>* news
<daviid>2011 actually. any other phone, os out there?
<daviid>replicant
<daviid>ah, any onr here uses it?
<daviid>we need to build guile on replicant
<paroneayea>daviid: the real target should be to get something in f-droid
<random-nick>daviid: replicant is basically android without google's proprietary software and without binary blobs and drivers
<random-nick>daviid: android is built around Java
<random-nick>daviid: but there is support for building native binaries
<daviid>paroneayea: f-droid, yes! random-nick thanks for the info
<daviid>i'd prefer a debian phone
<daviid>then
<random-nick>daviid: replicant is still fully free
<daviid>random-nick: but java .. teriible
<paroneayea>if something can go in f-droid
<paroneayea>it can work in replicant probably
<daviid>we need a phone running gnu linux
<paroneayea>yeah the n900 was the closest "realistic" dream of that
<paroneayea>ACTION misses their n900
<paroneayea>but nokia got bought by microsoft and etc and that dream died
<daviid>so as of today, no gnu linux mobile phone, even experimental?
<davexunit_>I don't know where we went so wrong that people that Android was the future of phone freedom and not GNU/Linux
<davexunit_>so many times I've brought up how you should be able to just install Debian or something on your phone and been laughed at
<daviid>davexunit_: google...
<daviid>it's not the people it is google
<davexunit_>that people thought*
<random-nick>basically anything from fdroid should in theory be able to go to an replicant phone, assuming replicant works and the app supports the android version and phone hardware
<daviid>people don't think :) otherwisxe fb would not even exists, neityer google, twiter ... people are manipulated, then they die :)
<random-nick>also, Android NDK (Native Development Kit), the program that is used for building native binaries for Android, uses clang instead of gcc
<daviid>even github manipulates most oof us...
<daviid>so imagine the lambda folks ... they beleive witout fb they would die ... have no life ... whithout android they wold be no life either, no phone ...
<daviid>but
<random-nick>NDK used gcc in the past so I think it shouldn't be hard to modify NDK to use GCC
<daviid>let's build 1! tomorrowe i open a factory and hire davexunit_ paroneayea our maintainers ...
<random-nick>but, the main problem is that Android doesn't use glibc
<random-nick>Android uses Google's own libc
<daviid>random-nick: we don't want android, we want gnu linux
<random-nick>Google really made it hard to make native programs on android
<random-nick>which is weird since performance is important on mobile phones
<daviid>at least I want gnu linux
<paroneayea>daviid: there's a lot of barriers there unfortunately :( both on the phone produciton side, and on having the right UIs
<paroneayea>daviid: but I too want gnu/linux
<paroneayea>even busybox/linux would be ok ;) but I want a more not-unixish userspace ;)
<random-nick>I think the most realistic approach would be to make a frankenstein system of android's driver and display stack + some custom userspace
<random-nick>and just reuse drivers from replicant
<random-nick>but even that is a very ambitious project
<random-nick>google made their own everything on Android...
<random-nick>paroneayea: have heard of the Neo900 project? https://neo900.org/
<paroneayea>random-nick: I have, but I've sunk so much money into hopes and dreams I'm waiting until something looks more alive
<paroneayea>I mean, the n900 and openmoko individually I already spent a lot of money and hope on... so a combined project... :)
<random-nick>also it should be considered that you can't have a fully open mobile platform because of the modem
<[df]>fwiw there is https://guardianproject.info/code/lildebi/
<[df]>I imagine it would be fairly easy to do similar with guix
<daviid>[df]: that is running debian on top of android, tha's not an option for me
<daviid>i'm looking for a gnu linux phone
<daviid>no android
<[df]>yeah it's not ideal
<[df]>even running gnu/linux you'd struggle to find free drivers for modern phone hardware
<[df]>my current compromise is that my phone is free software from userspace up
<daviid>neo900 is very promissing
<daviid>at least on the paper
<[df]>I had (well, probably still have somewhere) a neo freerunner
<[df]>if they solve the driver issue though, the next problem is a good touchscreen UI
<OrangeShark>Isn't there Ubuntu phones?
<avoine>daviid: if you want to use scheme on android, there is this project: http://www.lambdanative.org/
<daviid>avoine: i'd rather use kawa, but as i said, no andoird
<daviid>no android is my objective
<avoine>ok ok
<daviid>avoine: kawa is, up to what it can do due to the limitations of java and the catastrophic java oop 'model' (a humanity disaster), the best of the best scheme, on java I mean, and imo of course
<avoine>ok
<daviid>avoine: and last but not least, kawa is part of gnu
<avoine>yeah I didn't knew about it. looks good but I'm staying a far as I can to java and jvm :P
<daviid>avoine: so do I of course, ut when I need to (imagej ...) then I use kawa
<avoine>my interest with lambda native was not really the scheme implementation (gambit-c) but the scheme modules to interact with the phone (camera, accelorometer, audio, gps, UI, etc): https://github.com/part-cw/lambdanative/tree/master/modules
<avoine>so I can connect to a repl on an old phone and use it like a cheat IOT device (buzzword I know) with a screen, all in scheme
<guile-guest6>is there a guile build for windows
<OrangeShark>guile-guest6: someone posted before their window builds, let me see if I can find it
<OrangeShark>guile-guest6: https://github.com/Madsy/guile-automatic-build this is how they automate the builds and they have this to build automatic here http://guile.mechcore.net:8080/
<guile-guest6>OrangeShark: thank you
<madsy>guile-guest6: You have to wait a while for the latest version. The devs are reworking the binary format and interpreter/JIT which is incomplete for Windows.
<madsy>Or it was that when I made the script. Old 2.0.9 and 2.0.11 builds though.
<guile-guest6>madsy: sure
<paroneayea>avoine: oh interesting, I didn't know about lambdanative
<stis>hello guilers!
<stis>I'm wondering about how to compile native code for guile!
<stis>E.g. what options do we have to make this happen?
<stis>What about using gcc to compile functions that are fpic
<stis>and copy those functions to a byte vector and incorporate it in the .go file
<spk121>stis: convert functions originally written in guile to .go bytevectors? or store functions written in C/C++ as bytevectors in .go
<stis>e.g. store the position independent machine code in a byte vector in the .go file
<stis>and execute that memory as a function
<janneke>stis: have you seen ur-scheme?
<stis>no? what's their features?
<janneke>stis: http://canonical.org/~kragen/sw/urscheme/
<janneke>i guess you have heard of nash? that uses gnu lightning
<stis>yes, I heard about it, pretty cool. How portable is gnu lightning?
<janneke>stis: I haven't looked
<stis>The assembler path becomes hard when you want portability
<janneke>sure
<stis>GNU lightning provides a portable, fast and easily retargetable dynamic code generation system.
<stis>looks good
<spk121>stis: there is already a capability to call C-decl functions in shared object files from guile. Would that suffice?
<stis>Well consider compiling all scheme code to C that would mean a shared file per scheme file. I think it shouled suffice to just have a .go file
<spk121>stis: no reason one couldn't merge fpic obj files into a master .so file...
<spk121>stis: but to hava a master .go file, for current guile, would imply that all funcs are in the same module. If they were in different modules, that'd need support in upstream guile.
<stis>I think that I will play around a little with this.
<stis>It actually works. I compiled a function f to a shared library, loaded it and then got the bytevector representation of it, made again a function from the byte vector that was copied to another adress and executed it
<stis>one tricky thing was to get the saze of the function
<stis>here nm -S helps
<stis>the other tricky thing was to allow execution of a memory region
<stis>that was quickly fixed though using my aschm repository
<stis>otherwise the foreign code worked beutifully