IRC channel logs

2015-03-27.log

back to list of logs

<mark_weaver>dje42: I just noticed that 'gdbscm_open_memory' throws an error when 'size' is 0. why?
<mark_weaver>because of this, it raises an error when trying to print zero-length bytevectors. I guess we'll work around it on our end.
<nalaginrut>morning guilers~
<wingo>dsmith-work: hum, will look into that some time
<wingo>dsmith-work: coverage should work in master, but the implementation had to change due to the compiler/vm changing
<wingo>so it's possible i made bugs
<wingo>mark_weaver: cool! no immediate plans to change -- currently experimenting with a different style of cps representation
<ArneBab_>I’d love to see something like this is guile: https://www.youtube.com/watch?v=v5dYE0CMmHQ ← considerations down to the L1 cache access time.
<b4283>i have a question
<wingo>meep
<b4283>if (read-char) is defined in a lambda X, and X is evaluated with a different (current-input-port)
<b4283>which port does (read-char) read from ?
<b4283>(with-input-from-file X (lambda () (let ((c (lambda () (read-char)))) (with-input-from-file Y (lambda () (c)))))
<b4283>something like this
<b4283>experimenting shows that it reads from Y, the latter context !
<b4283>another question: is there a way to quickly map a file into memory like mmap ?
<b4283>i realize that just reading a big file takes 4 seconds with read-char
<b4283>read-line is faster, but still takes 2 seconds
<wingo>b4283: the current input port is a dynamically bound variable
<wingo>it's a parameter
<wingo>see the manual about parameters
<wingo>so the closure doesn't capture the value of the port at the time it was created
<wingo>it captures the parameter
<wingo>whose value can change
<wingo>it's like stdout
<wingo>you can make "cat" write to a file or /dev/null
<wingo>or whatever
<wingo>depending on what the value of the stdout "dynamic variable" is
<wingo>current-output-port is like that
<wingo>b4283: to read a whole file there is a procedure for that
<wingo>to read it as a string
<wingo>of course the result depends on character sets
<wingo>there is no mmap wrapper yet; patches welcome tho :)
<jao>wingo, hi! do you know what's the current guild story? i wish we had something like this http://docs.racket-lang.org/pkg/ at the cli level
<wleslie>greetings jao!
<wleslie>do you still write a blog? I really enjoyed programming-musings
<wleslie>ok. maybe it's not so out of date.
<wleslie>need to remember to check the jao.io blog rather than the old programming-musings.org.
<jao>wleslie, yep, that's the current one... but i write very little these days :(
<wingo>jao: hi :)
<wingo>i don't know what the current guild story is. to an extent it has lost steam -- well if it had it :) -- due to guix
<wingo>because the space is the same, somehow, and guix does appear to solve it well.
<wingo>but it's not a good situation
<wingo>because right now we effectively disincentivize people that don't commit to guile proper
<wingo>because we don't want to add too many things to guile core, but we should enable people to share their work better
<davexunit>there's a still a use-case for the guildhall, despite guix being around.
<wingo>dunno. it's a solveable situation but it might need a champion of some sort
<wingo>davexunit: how do you see guildhall vs guile?
<davexunit>vs guix, you mean?
<davexunit>guildhall is a language-specific package manager, like pip, npm, bundler, composer, etc.
<davexunit>which I'm personally not crazy about, but...
<davexunit>it would be a lot simpler for folks on whatever OS they use to install guile packages via the guildhall
<davexunit>than to setup Guix, which is a general-purpose package manager.
<davexunit>notably, Guix would need a port to XNU in order to be used on OS X.
<jao>i don't know guix well, but it doesn't look as convenient as a scheme-specific package manager where you can, for instance, install libs from a github repo... but probably i'm wrong
<davexunit>so if there was no guildhall, people that wanted Guile packages would be out of luck if no one wanted to maintain an XNU port.
<davexunit>guix has any language-specific package manager beat, hands-down, in terms of functionality, elegance, etc.
<davexunit>but if you *just* want to get some Guile libs, it's overkill.
<davexunit>enter guildhall. :)
<davexunit>but guildhall could never do the advanced things that guix does. pretty useful things, I might add.
<davexunit>I have this file in my game engine's repo: https://gitorious.org/sly/sly/source/a915b370094a59f868b6d49ab50e10c062600b46:package.scm
<davexunit>as a Guix user, you can simply run 'guix environment -l package.scm' and you'll be put into a shell with *everything* needed to build and run Sly.
<davexunit>including all of the non-guile stuff.
<unknown_lamer>hrm, if guix is written in guile
<unknown_lamer>guile has define-syntax, why not build a high level abstraction with limited flexibility that expands down into a full blown guix recipe...
<unknown_lamer>to replace something like guildhall
<davexunit>unknown_lamer: it's a matter of scope, I think. Guix includes an entire GNU/Linux distro!
<davexunit>and in order to use Guix on a new platform, the bootstrap binaries must be ported to that platform. it's a lot of overhead for just grabbing a scheme file or two.
<davexunit>so, I think guildhall can satisfy the basic needs of "install this guile lib from this git repo"
<davexunit>and guix can satisfy advanced, full system integration needs.
<unknown_lamer>ah, bummer, didn't realize it wasn't easy to use separately from the distro
<davexunit>well, you can use it anywhere we have a port for it.
<davexunit>I'm using it on Debian right now.
<unknown_lamer>ooo
<davexunit>but it includes a distro of packages and all sorts of other features that are awesome, but far beyond the scope of "give me that lib on github"
<unknown_lamer>davexunit: s/github/kallithea/ ;)
<davexunit>;)
*davexunit still doesn't know where to move his repos
<davexunit>might just move them to my own server and use gitweb
<unknown_lamer>davexunit: git.hcoop.net ;) but if you already have your own server, setting up gitweb is really easy
<davexunit>yeah, I set it up at the FSF recently
<unknown_lamer>simple config, just set up a boring old cgi in whatever webserver you are using and point gitweb.conf to your repos, pretty much done
<davexunit>gitolite backend
<davexunit> https://vcs.fsf.org
<unknown_lamer>cool
<unknown_lamer>hrm, gitweb looks a bit different than the one I have
<unknown_lamer>what version is that?
<davexunit>I used a theme
<unknown_lamer>work is using the same theme ha
<unknown_lamer>but what theme is it, it is nicer than the default...
<unknown_lamer> http://kogakure.github.io/gitweb-theme/ this I guess, neat
<davexunit>yup, that's the one
<ArneBab_>Conceptually guildhall could be a specialized overlay to guix: Assuming that guile is available and that every package is packaged following the guildhall rules means that it’s only necessary to specify the package dependencies.
<ArneBab_>Maybe guix could even import guildhall available.scm files and transform them into full guix recipes automatically.
<ArneBab_>it would be an EDSL inside the guix EDSL ☺
<ArneBab_>one line¹ vs 30 lines² ¹: https://github.com/ijp/guildhall/blob/master/tests/repository/discrepancy/pkg-list.scm ²: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n331
<davexunit>ArneBab_: yes, but that first one couldn't be meaningfully used by guix
<davexunit>no cryptographic hashes or anything to verify integrity
<ArneBab_>would these be more trusted than the packages, given that both lies on the same (remote) webspace?
<davexunit>well, what if the download was corrupt?
<davexunit>guix will notice
<davexunit>guildhall wouldn't
<ArneBab_>there is already “update the list of GNU packages”, which does something similar
<ArneBab_>refresh IIRC
<davexunit>yes, we have helpers like that
<davexunit>we can certainly write an import script for guildhall
<dsmith-work>Happy Friday, Guilers!!
<davexunit>but I think the line comparison is a little unfair
<ArneBab_>happy friday dsmith-work!
<davexunit>the guix package has lots more metadata
<ArneBab_>davexunit: I used the line comparison to show that it’s much easier to create a guildhall script, because it does less than guix.
<ijp>it is unfair
<ijp>source field aside, the rest is basically identical in a normal pkg-list.scm
<davexunit>ah, okay.
<ArneBab_>a question would be: why should someone put something in the guildhall instead of directly putting it into guix?
<davexunit>ArneBab_: different user bases?
<ArneBab_>like reaching everyone who has guile installed on any distro?
<davexunit>guildhall works on OS X (afaik), guix doesn't.
<ijp>I could see guildhall being replaced with a specialised guix repo, and doing away with the separate implementation
<ijp>I'm not working on it, rotty isn't working on it, and guix is pretty healthy
<davexunit>heh, maybe motivation to port to XNU? :)
<ArneBab_>what keeps guix from working on OSX?
<ArneBab_>and would that apply to a specialized guix repo, too? (which does not need the distribution-parts of guix)
<davexunit>needs bootstrapping
<davexunit>guix uses only its own package builds to do things, starting from the bootstrap binaries.
<ArneBab_>so you can’t use external things which are already on the system
<davexunit>exactly.
<ArneBab_>that is a pretty hefty limitation…
<ArneBab_>(for just distributing guile packages)
<davexunit>because reproducible builds would be thrown out the window
<davexunit>Nix works on OS X, so we'd just need some folks that wanted to run Guix on OS X and it could be done.
<ArneBab_>yes. This makes it unusable for someone who wants to bind an OSX-specific library
<davexunit>well... that's an issue in guildhall, too?
<davexunit>I don't know guildhall works with building native code
<davexunit>know how*
<davexunit>I thought it was for pure scheme modules
<ArneBab_>(or anything distro-specific which relies on something from the local distro)
<davexunit>you'd have to solve that problem with guildhall, too...
<ArneBab_>I think in guildhall you could just assume that what you need is there (and let the user deal with missing libs)
<ArneBab_>the usecase is much easier (for the package manager and the packager)
<davexunit>I'm confused. are you talking about libraries needed to build?
<davexunit>or that are dlopened via dynamic-link or something?
<davexunit>because the latter wouldn't be a problem
<ArneBab_>ijp: does guildhall support building C extensions and such?
<davexunit>(if you left them out as inputs, since they're only used at runtime)
<davexunit>but yeah, guildhall is much simpler because it's not trying to build a bit for bit reproducible distribution.
<ijp>ArneBab_: IIRC, it can in theory
<davexunit>so, by all means, continue to hack on guildhall.
<ArneBab_>ijp: practically guildhall appeals to me, because whenever I installed guix as a local overlay, that was quite some work and it broke after a few months, while I setup guildhall once (in a few minutes) and it kept working. That’s the value of doing just what I needed there. (and I only needed a fast way to get foof-loop)
<ArneBab_>with local overlay I mean: Just for my own user.
<ArneBab_>It would be cool, however, to have an automated way to tie guildhall into guix, so everything available in guildhall repos would be available in guix by default.
<davexunit>well, we could write an importer without too much fuss, but we'd still have to maintain those packages mostly by hand.
<davexunit>automatic importing is no good for anyone.
<ArneBab_>yepp - something like what’s done for the GNU package releases.
<civodul>Hello Guilers!
<civodul>sneek: seen ijp
<sneek>ijp was here Mar 27 at 04:08 pm UTC, saying: ArneBab_: IIRC, it can in theory.
<ArneBab_>civodul: hi
<ArneBab_>civodul: we talked about whether guix could import guildhall repositories similar to how it imports gnu package releases (via guix refresh)
<mark_weaver>ArneBab_: we'd probably put it in 'guix import' rather than 'guix refresh', but yes, it would certainly be straightforward to write an importer for guildhall packages
<daviid>working on the autotool chain for kisê... calling guild compile upon individual modules is not good because some settings are [usually] done in the main app script, such (eval-when (expand load eval) (default-duplicate-binding-handler '(merge-generics replace warn-override-core warn last))) [this is just an example, there maybe other settings], what can I do to solve this ?
<daviid>s/is not good/does not work
<daviid>I can define a 'settings' module and import it in all others... but would it not be nice|better to be able to ask guild compile to import a module before it start to compile?
***dje is now known as xdje
<mark_weaver>daviid: if you need to load settings in order to compile code, that's a problem because it suggests that the settings might affect the result of compilation.
<daviid>well it does yes :)
<mark_weaver>settings presumably are data relevant at run-time only
<mark_weaver>if settings can affect compilation, then you cannot compile ahead of time safely
<daviid>yu can if you have a way to pass the setting
<mark_weaver>I'm sorry, I'm working at radio now, can't talk much
<daviid>not all settings are runtime settings: merge-generics must be set before any module expansion ... as you know of course
<daviid>mark_weaver: that's ok
<mark_weaver>I would make a module and import it from the other modules
<daviid>i will tempo write s (kise settings) module ust for that merge-generics option i need
<daviid>mark_weaver: i suggested that as well, but it's a bit 'funny' and 'hacky', since i have to do that because of guild compile 'limitation', not because of guile... i think we should think about that and improve guild...
<mark_weaver>I don't know of any other compiler that lets you specify on the command line the equivalent of "#include" to be prepended to the file. seems silly to me. if you want that, just put the #include at the top of the file.
<mark_weaver>to my mind, modules should specify their prerequisites at the top of the file
<daviid>then we should remove from guile and the manual any global setting
<daviid>a global [guile] should only be set/imported once, not in every individual module, i think
<mark_weaver>well, global settings are very problematic, because if module A requires global setting FOO=BAR and module B requires global setting FOO=TOT, then you can't combine A and B into a single program.
<mark_weaver>so I would agree that we should try to move away from such global settings
<daviid>that becomes a user responsibility
<mark_weaver>however, you don't have to make those settings in every module. you do it one in module and then import that module from the modules that need it.
<mark_weaver>surely you already have other widely-used kise variables/procedures that are widely needed, so you already have to import those
<mark_weaver>anyway, I have to go afk...
<daviid>ok, talk later