IRC channel logs

<ArneBab_>when I run par-map like the following, a few times it went into single-stepping after some time even though I have 4 cores: (use-modules (ice-9 threads))(par-map (λ (x) (sleep 1)(display x)(newline)) (iota 100))

<ArneBab_>^ do you also see this?

<ArneBab_>it’s as if it uses threads…

<taylan>ArneBab_: can reproduce on 2.0.11 and 2.1.1

<ArneBab_>bug found! — first step to fixing it ☺

<ArneBab_>taylan: thanks for checking!

<taylan>ArneBab_: in par-for-each the bug "activates" later it seems

<taylan>but is still there

<sea``>Hi, I can't figure out how to send eof to a pipe and shutdown the input mode. How is this done in guile scheme?

<davexunit>I'm not sure how to close one side of a pipe off the top of my head

<davexunit>there's a variable called 'the-eof-object' that you might be able to use.

<taylan>AFAIUI the eof-object is unprintable, and unrelated to ASCII EOF

<davexunit>oh

<davexunit>thanks :)

<sea``>I'm starting to think guile /can't/ close one half of a pipe

<sea``>I've looked everywhere in the manual by now

<davexunit>that may be true

<lloda>does this help: http://paste.lisp.org/display/159368

<taylan>documentation for `pipe' says: Return a newly created pipe: a pair of ports which are linked together on the local machine. The CAR is the input port and the CDR is the output port.

<sea``>Yay it works! Thanks. I rewrote the (receive...) part with (let ((results... and swapped some stuff but it works now

<dsmith-work>Happy Friday, Guilers!!

<daviid>happy friday!

<daviid>davexunit: congrat! the announcment is super well written as well!

<davexunit>daviid: thank you!

<civodul>ooh yeah, congrats for the release, davexunit!

<civodul>and happy Friday! :-)

<davexunit>thanks civodul

<civodul>the "callback hell" is a plague

<civodul>it's great that Sly addresses it this nicely

<davexunit>yes, that was the big breakthrough for me.

<civodul>the work of remi`bd on GNUnet suffers from being imposed that callback hell

<davexunit>:(

<civodul>but since the GNUnet libs are C, we can't use delimited continuations to invert IoC

<civodul>:-/

<davexunit>yeah :/

<davexunit>Sly is coroutines on bottom, reactive programming on top

<civodul>yeah

<davexunit>it's completely changed the way I approach interactive program development

<davexunit>finally I had identified what made normal game development so tedious and difficult.

<civodul>heh, i can imagine :-)

<davexunit>and people had already developed an abstraction to solve it.

<civodul>i wonder if there's a known approach to invert IoC of C libs

<davexunit>underneath it all, it *is* asynchronous, discrete events, but users shouldn't be subjected to such things!

<ArneBab_>davexunit: I need/want to make time to try Sly

<davexunit>well I hope the release gives you the motivation ;)

<davexunit>I recommend trying out the example 2048 clone :)

<neiljerram>me too.

<neiljerram>I recently wrote some Guile code to start trying out various automatic strategies for 2048...

<neiljerram>it would be fun to see if that could be easily plugged in, and I guess use your engine as its visualizer

<davexunit>it's definitely possible

<civodul>oh, hi, neiljerram!

<neiljerram>hi ludo!

<civodul>good to see you here :-)

<civodul>and probably at FOSDEM i guess?

<neiljerram>yes, I will be at FOSDEM.

<civodul>cool

<neiljerram>BTW, not sure yet if I can come for both days. If I only come for 1 day, would you recommend Saturday or Sunday?

<davexunit>depends on when the guix talk is

<civodul>there's a bit more stuff on Saturday

<civodul>Sunday people typically start leaving around 4pm

<civodul>but yeah, depends on what talks you want to attend

<neiljerram>going to look at the schedule now...

<neiljerram>seems there is no confirmed schedule at all yet... am I misreading?

<civodul>no it's expected

<neiljerram>I guess it's just too early at the moment!

<civodul>people are still in the process of submitting talks

<civodul>right :-)

<neiljerram>I will probably be around in IRC more reliably from now on. Reason is that I'm doing a lot of OpenStack work, and they use IRC a lot - but I keep missing things because I hadn't sorted out having a proper IRC setup running all the time, alerting and so on.

<neiljerram>I hope I've done that now - using XChat - and hence should become a more predictable IRC user.

<civodul>good :-)

<neiljerram>thx :-)

<civodul>so many people working on OpenStack!

<neiljerram>Yeah, it's crazy. Was just at the summit in Tokyo....

<neiljerram>It's actually a really nice community, though.

<neiljerram>And I have to be fair - even here :-) - and say that (1) Python has its merits, and (2) the Python community has a very positive and more diverse feel to it than some other parts of software.

<neiljerram>But I still love Guile too!

<civodul>heheh :-)

<civodul>did you read that one: http://blogs.rdoproject.org/7843/guix-tox-a-functional-version-of-tox

<civodul>might be a way to put bits of Guile into OpenStack ;-)

<neiljerram>wow, I didn't see it before, but looks interesting.

<neiljerram>A lot of electrons are burnt on the mailing list over requirements. It's not an area I've really ramped up on yet, but I'll certainly look at that blog.

<Steap>Hum, so people are talking about Guile and OpenStack here?

<civodul>precisely

<neiljerram>Well, just a brief interlude, I think.

<civodul>Steap is very well informed ;-)

<davexunit>a guile openstack client would be gerat

<davexunit>great*

<civodul>so Steap is the author of that guix-tox article i mentioned

<davexunit>for use in guix :)

<civodul>yep!

<davexunit>I want to deploy GuixSD systems to OpenStack

<Steap>davexunit: there is a Common Lisp client :)

<davexunit>also, an EC2 client would be cool for using private clouds that compatible, such as OpenStack and Eucalyptus.

<Steap>davexunit: like, run GuixSD on OpenStack ?

<Steap>That is basically running GuixSD in kvm

<davexunit>private clouds that are compatible with EC2**

<Steap>funnier thing would be to run OpenStack on GuixSD :)

<davexunit>Steap: but to be able to automatically provision and deploy on openstack is the thing

<Steap>It might be easier to debug all the crashes using a functional OS

<davexunit>a la the WIP 'guix deploy'

<Steap>davexunit: well as long as you ahve an ISO or bootable somethign

<Steap>that should work

<davexunit>sure but what's missing is the automation part

<davexunit>something to talk to the API

<davexunit>provision the machines

<davexunit>boot them, upload the guixsd closure

<neiljerram>Oh I see, you mean the original ISO would be just some minimal base system

<davexunit>perhaps.

<Steap>we do not even have ISOs for some reason :(

<davexunit>I want to make N guixsd machines on openstack via a convenient guix tool.

<neiljerram>And then a central Guix controller could manage the extra bits on top of that, for a whole set of VMs

<davexunit>yes

<davexunit>a la ansible, chef, puppet, but better.

<Steap>yeah, another tool

<Steap>I need more buzzwords for my meetings

<davexunit>guix already does full-system config management

<davexunit>it just needs the tools to manage remote machines

<davexunit>and many of them

<neiljerram>It wouldn't really need a Guile OpenStack client, though. More a control channel between the Guix controller and the base Guix system on each VM

<davexunit>neiljerram: but there wouldn't be a VM to talk to without using a client to create it

<neiljerram>Oh sure, yes

<davexunit>the Nix folks have a tool called NixOps for this purpose

<davexunit>I want the same for guix

<neiljerram>Is there already a well-defined concept of a 'base' or 'null' state in Guix?

<davexunit>we don't really have state.

<davexunit>we have a 'guix system init' tool that installs a system config for the first time somewhere.

<davexunit>but the configs themselves are stateless

<jjwatt>i would be very interested in guix for remote deployment and config/admin

<davexunit>I don't know if we'd want to build a disk image for each deploy, or start from some known image.

<davexunit>assuming a running system, it's easy to copy the "closure" of a guixsd system to a remote machine and then instantiate it.

<neiljerram>(I need to step away now, but will keep the idea of a Guile OpenStack client in mind!)

<Steap>not sure whether another client is that important

<Steap>as a library, maybe

<davexunit>it is.

<davexunit>to talk to openstack with pure guile

<Steap>davexunit: OpenStack has a REST API

<davexunit>sure

<Steap>you can talk to OpenStack using Guile

<davexunit>yes, a client

<davexunit>that abstracts that

<Steap>yeah, or just call the existing CLI clients...

<davexunit>that is unideal

<davexunit>a guile client is much more flexible

<davexunit>shelling out is giving up

<Steap>you reming of that Haskell guy I know

<Steap>who is currently rewriting *everything* in Haskell :p

<daviid>ACTION thinks even the os should be written in scheme

<davexunit>having libraries in your language for these things is very advantageous

<daviid>even the bios actually

<jjwatt>hah "shelling out." "Don't be a shell-out."

<davexunit>:)

<davexunit>but since openstack uses a REST API, it shouldn't be too hard to write guile procedures to do the RPC stuff

<cmhobbs>can i do string interpolation with guile?

<fantazo>it has strings. and you can access them.

<davexunit>cmhobbs: see 'format'

<davexunit>there's no string interpolation syntax a la ruby though, and I think that is a feature :)

<davexunit>I mostly use string-append for my string building needs

<fantazo>the syntax in ruby is a method call too.

<fantazo>but sure before that some syntax mangling happens.

<fantazo>but then is the question if lisp macros, which guile also supports, are as bad as ruby syntax.

<fantazo>(I must say I haven't yet grasped clean-macros)

<cmhobbs>yeah, just looking for a way to get some stuff out of a hash table and into a string

<davexunit>object->string

<cmhobbs>well not the entire hash table

<cmhobbs>just bits of it

<cmhobbs>i'll work it out

<cmhobbs>so this bit of code works and returns a hash table but i'd like to throw that hash table into a variable so i can do useful things with it: http://paste.lisp.org/display/159389

<add^_>maybe I should give guile another chance..

<cmhobbs>most of my attempts yield either 'wrong type to apply' or a bunch of esoteric stacktraces

<cmhobbs>that i don't fully understand

<cmhobbs>any tips?

<cmhobbs>i might be structuring this all wrong, too

<cmhobbs>i'm going to sit down this weekend and hammer through the guile docs and work on a couple of toy projects so i stop making wierd mistakes like this

<cmhobbs>add^_: i'd recommend it. i'm having fun, at least

<add^_>I know it's fun

<add^_>I used to use guile, but I got tired of some things

<add^_>but I'll see if it's improved :-)

<add^_>Guile when being used is amazing though

<add^_>installation isn't as much fun though

<add^_>even though it's a nitpick

<add^_>don't let me scare you though :-)

<add^_>The new page looks nice too, whoever made it!

<fantazo>is guile still not a good idea to use in games?

<cmhobbs>(define foo (parse-user-data (fetch-response-body "someurl"))) returns "wrong type to apply: hahsable" when i call (foo) and (define foo parse-user-data (fetch-response-body "someurl")) returns "Throw to key `r6rs:exception' with args `(#<r6rs:record:&raise-object-wrapper>)'."

<add^_>why wouldn't it be?

<cmhobbs>fantazo: i think so

<cmhobbs>i think it's a good idea, that is

<fantazo>slow garbage collector? maybe memory leaking? I remember that there were issues like this a couple of years ago with guile

<fantazo>and besides that it's uncomfortable to use it in C projects.

<add^_>well, if you wanna make AAA games or really hardcore stuff I always say do it in C... But I don't really think anyone cares what I say anyway :-P

<add^_>So I guess it's more of a question what you are most comfortable with

<add^_>:-)

<add^_>(equal? boehm-gc-7.4.2 libgc)

<add^_>I'm wonderinf if I should install boehm-gc since my repo doesn't find libgc

<add^_>so I was wondering if they are the same thing

<add^_>just a different name

<add^_>(working on installing guile again)

<jjwatt>add^_: I think they're the same

<jjwatt>add^_: had the same thing installing git guile on ubuntu at work

<jjwatt>add^_: oh, but mine was the opposite. ubuntu has libgc-cev

<jjwatt>*libgc-dev

<jjwatt>the bdwgc repo seems to indicate that they're the same: https://github.com/ivmai/bdwgc/

<add^_>ah

<add^_>ok

<add^_>thanks

<davexunit>fantazo: I am working on a game engine in guile. there are certain challenges, but the upcoming Guile 2.2 has greatly improved performance

<davexunit>and has also introduced optimizations for things that games need

<davexunit>floating point ops in particular

<fantazo>davexunit, oh I'm glad to hear that :-)

<cmhobbs>i annotated the paste with the errors i'm getting from hashtable procedures: http://paste.lisp.org/display/159389#1

<cmhobbs>any thoughts?

<jjwatt>do you have some control over GC in guile?

<davexunit>jjwatt: there's a few knobs to tweak

<davexunit>cmhobbs: looks like you're mixing hash table implementations

<cmhobbs>hm

<davexunit>guile has its own hash table type, which is what guile-json uses

<cmhobbs>i'll look at guile-json's source and see if i can use their hash tables, i guess

<davexunit>but the R6RS spec has a separate, incompatible hash table implementation

<davexunit>confusing, but that's the way it is.

<cmhobbs>where are the docs for guile's built in stuff? i got rnrs hashtables from the guile reference manual

<cmhobbs>i just need to get a the value of a key out of that hash table and pass it to a system call

<davexunit>cmhobbs: section 6.7.14

<davexunit>hash-ref, hash-set! and friends

<cmhobbs>kk

<add^_>Update: installation has been pretty smooth so far.

<add^_>:-D

<cmhobbs>davexunit: you nailed it. is there any way to catch that sort of thing in the future? i feel dumb for running into this sort of stuff

<davexunit>the type error was the red flag

<davexunit>and other than that, just knowing some quirks about guile.

<cmhobbs>ok, great

<cmhobbs>mostly back on track then :D

<davexunit>great

<cmhobbs>now to figure out how to reference the keys... i can iterate over them with hash-for-each and display all the data but i can't get data out with hashq-ref and a string for a keyname

<cmhobbs>or whatever the 'foo syntax denotes

<cmhobbs>ACTION absorbs more guile reference

<davexunit>guile-json using hash tables is one of the reasons why I don't really like guile-json

<cmhobbs>i'll have a mental image of this entire document by the end of next week

<cmhobbs>well it's the only option i've got right now, yeah?

<davexunit>yup

<cmhobbs>a list would make sense

<davexunit>just saying for the record ;)

<cmhobbs>ha

<cmhobbs>i don't have to use json for this

<cmhobbs>it's just a string that i'm setting

<cmhobbs>so that string can be any format

<davexunit>my pending (ice-9 json) module uses alists

<cmhobbs>so if there's a better string format to mangle into a data structure, let me know

<davexunit>so, there isn't a 'hash-keys' procedure or anything

<davexunit>but it's trivial to implement with 'hash-fold'

<ft>use s-expressions and "read" the string.

<davexunit>(hash-fold (lambda (key value result) (cons key result)) my-hash-table)

<davexunit>er

<cmhobbs>what does the 'foo syntax denote?

<davexunit>(hash-fold (lambda (key value result) (cons key result)) '() my-hash-table)

<davexunit>cmhobbs: that's a symbol

<cmhobbs>ah-ha!

<davexunit>like :foo in ruby

<cmhobbs>man, that just turned on the lightbulb in my brain

<cmhobbs>wouldn't that hash-fold just yield all the keys as strings?

<davexunit>'foo is short for (quote foo)

<davexunit>cmhobbs: it yields all the keys as whatever their type is

<davexunit>the keys can be of any type

<cmhobbs>hashq-ref won't take a string though

<cmhobbs>all my keys are strings

<cmhobbs>if it takes a string, it'll just return #f as in "not here"

<cmhobbs>even if it's there

<jjwatt>can you turn a string into a symbol?

<cmhobbs>i don't think my keys are symbols

<ft>string->symbol

<cmhobbs>they came in via json as strings and got mashed into the hashtable as strings

<davexunit>cmhobbs: hashq-ref uses the eq? function for matching keys

<davexunit>you want hash-ref

<davexunit>which uses equal?

<davexunit>which will DTRT for strings

<cmhobbs>bingo

<kori>j #sly

<kori>whoops

<wirrbel>is there a way to get slices of lists?

<koz_>wirrbel: Define 'slice'.

<wirrbel>for example a new list, containing elements i to k of the input

<koz_>wirrbel: There's take and drop.

<koz_>(in SRFI 1)

<koz_>You can easily combine them to create a 'sublist' function.

<wirrbel>uh, okay, I had just been looking at srfi 1 but thought that take and drop where working on predicates

<wirrbel>so I skipped them without taking a closer look

<wirrbel>great

<koz_>Nope, they just go by indices.

<koz_>split-at might also warrant your attention.

<koz_>The predicate-based versions are filter and friends.

<koz_>Well, remove, take-while, drop-while, etc as well.

<koz_>Probably the easiest way to write a sublist function would involve a combination of split-at and drop.

<koz_>(and just ignoring the second list)

<koz_>Although to be honest, if you wanna take slices, you're probably better off (for efficiency reasons) using vectors.

<koz_>(lists have O(n) indexing)

<koz_>This may seem like a daft question, but when I wanna make a module that imports other modules, I do (define-module (foo blah) ...) and then (use-modules (ice-9 make-tea) (srfi srfi-1) ... ) , right?

<davexunit>(define-module (foo blah) #:use-module (srfi srfi-1) ...)

<koz_>davexunit: Ah, I see. Do I need multiple #:use-module statements if I wanna include multiple modules?

<davexunit>yes

<koz_>OK, cool, thanks.

<koz_>ACTION has realized he can rewrite his structure as a state machine.

<koz_>Also, Guile has a much saner module/namespace approach than any other Lisp I've used.

<koz_>I had to look up Clojure's ns macro and CL's package stuff practically every time I wrote the damn things.

<paroneayea>I wish guile encouraged prefixing things by default, but I really like guile's modules system a lot

<paroneayea>especially

<paroneayea>because of the live hacking aspects

<paroneayea>with geiser integration

<paroneayea>the fact that you can change and evaluate something inside a module

<paroneayea>and it's auto-propagated to all other modules that imported it while live hacking at the repl

<paroneayea>that is straight up incredible to work with

<koz_>Yup!

<koz_>Also, does the list to #:export have to be quoted?

<koz_>I assume so, but since define-module is probably a macro, I could be wrong.

<davexunit>no quote

<koz_>davexunit: OK, thanks.

<koz_>davexunit: SRFI-64 seems to keep a history of test passes/failures by default. Is there a way I can have it *not* do that?

<koz_>(history = over multiple test runs)

<cmhobbs>alright, my big fat pile of guile got accepted by my lead def

<cmhobbs>dev

<cmhobbs>so now to keep throwing guile things together at work and hope it gets adopted more widely

<koz_>Lol@lead def.

<koz_>The lead definition.

<cmhobbs>haha yeah

<cmhobbs>i'm so glad that i'm not a lead dev or cto anymore

<cmhobbs>senior dev is where i like to be

<cmhobbs>slingin' code, not dealing with filthy humans

<cmhobbs>and their breathing

<cmhobbs>and typing

<cmhobbs>and "but i want to go hooooome"

<koz_>Lol.

<mark_weaver>koz_: you can completely customize the way that SRFI-64 records/reports tests. the default logging is done by the default "test runner". see the "Writing a new test-runner" in the SRFI-64 document <http://srfi.schemers.org/srfi-64/srfi-64.html>

<cmhobbs>thanks for all the help today, folks. i'm going to take off for a bit

<mark_weaver>for example, test-suite/tests/srfi-64.test in the guile source tree defines a simple test runner that passes along the results to guile's own test suite.

<koz_>mark_weaver: Thanks, I'll look into that.

<koz_>If I'm going to be hashing symbols, should I use hashq for my vhash?

<koz_>(like, vhash-consq etc)

IRC channel logs

2015-11-13.log