<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. <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 <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>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>see the manual about parameters <wingo>so the closure doesn't capture the value of the port at the time it was created <wingo>you can make "cat" write to a file or /dev/null <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>of course the result depends on character sets <wingo>there is no mmap wrapper yet; patches welcome tho :) <wleslie>do you still write a blog? I really enjoyed programming-musings <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>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>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>but guildhall could never do the advanced things that guix does. pretty useful things, I might add. <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. <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... <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>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" *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 <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 <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 ☺ <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? <ArneBab_>there is already “update the list of GNU packages”, which does something similar <davexunit>we can certainly write an import script for guildhall <davexunit>but I think the line comparison is a little unfair <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>source field aside, the rest is basically identical in a normal pkg-list.scm <ArneBab_>a question would be: why should someone put something in the guildhall instead of directly putting it into guix? <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 <ArneBab_>and would that apply to a specialized guix repo, too? (which does not need the distribution-parts of guix) <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>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>I don't know guildhall works with building native code <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? <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. <ArneBab_>yepp - something like what’s done for the GNU package releases. <sneek>ijp was here Mar 27 at 04:08 pm UTC, saying: ArneBab_: IIRC, it can in theory. <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>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. <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 <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