***dsmith is now known as dsmith-work
<paroneayea>davexunit_: I was just about to post that here :) <davexunit_>my expectation is that we're interested in having our own compiler and VM <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 <avoine>but maybe user friendlyness should be the next goal? <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>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>2011 actually. any other phone, os out there? <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: but there is support for building native binaries <daviid>paroneayea: f-droid, yes! random-nick thanks for the info <daviid>random-nick: but java .. teriible <daviid>we need a phone running gnu linux <paroneayea>yeah the n900 was the closest "realistic" dream of that <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>it's not the people it is google <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 ... <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 <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 <paroneayea>daviid: there's a lot of barriers there unfortunately :( both on the phone produciton side, and on having the right UIs <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 <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]>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 <[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 <[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 <daviid>avoine: i'd rather use kawa, but as i said, no andoird <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 <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>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 <OrangeShark>guile-guest6: someone posted before their window builds, let me see if I can find it <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. <paroneayea>avoine: oh interesting, I didn't know about lambdanative <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 <stis>no? what's their features? <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? <stis>The assembler path becomes hard when you want portability <stis>GNU lightning provides a portable, fast and easily retargetable dynamic code generation system. <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>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