IRC channel logs

<ijp>cky: it's not

<civodul>ijp: in what sense?

<ArneBab>civodul: Do you mean making Guile more of a batteries included system?

<ArneBab>(more focus on providing good modules with solutions for many situations?)

<cky>ArneBab: True, re Dvorak being optimised for English.

<ArneBab>cky: in my case that was the death knoll for Dvorak: I need to write at least 30% in german, so a keyboard layout has to work both for german and for english.

<nalaginrut>morning guilers~

<civodul>Hello Guilers!

<amirouche>I have a doubt I wrote all my code with bytevector procedures.... but seems like I'd rather use lists and convert the thing to bytevector when done

<taylanub>amirouche: https://gitorious.org/taylan-guile/bytestructures/ (tell me if you want me to backport features from the RnRS version)

<amirouche>taylanub: I'm not sure what it is, hence how it can be useful to me.

<amirouche>the problem I have is that I don't know the size of the bytevector in advance, so I alwasy create a new one a copy two bytevector into it

<amirouche>I use (bytevector-append) (bytevector-take) & (bytevector-drop)

<amirouche>similar to string procedures

<taylanub>what exactly are you using bytevectors for?

<amirouche>serialization of numbers and strings

<amirouche>my main function are (pack format . rest) and (unpack fmt bv)

<taylanub>then bytestructures might be useful. I'm afraid the intro of my README is way too heavy on made-up terminology :(

<taylanub>amirouche: do you know C well?

<amirouche>kind of

<taylanub>you might have noticed that *everything* has an underlying char* in a sense; the raw underlying memory (maybe not in the specification's terms, but in practice anyway)

<taylanub>bytevectors are char* too. and bytestructures are C's type system for bytevector.

<taylanub>so you can define integer types, floats, "array of x with legth y" types, struct types, etc., and use the accessors of those, instead of using bytevector accessors directly

<taylanub>number types, vectors, structs, unions, and even pointers (for Guile only) are in the bytestructures stdlib so to say; others can be defined if you need

<amirouche>ok I think I get it

<taylanub>(define bs (bytestructure `(,bs:vector 5 (,bs:struct (x ,uint8) (y ,float)))))

<taylanub>(bystestructure-set! bs 3 'y 0.3)

<taylanub>-> bs[3].y = 0.3;

<amirouche>I get it

<taylanub>(very verbose .. might want to use an import renamer that does s/bytestructure/bs/ or so)

<taylanub>note it adds a lot of overhead. readme has a performance section at the bottom.

<amirouche>I use bytevector to have a contiguous memory C side and then use the pointer as data->item (and length as data->length). The data structure is then used in a C call.

<cky>taylanub: Personally I'd make some macros to avoid all that crazy unquoting, but that's just me.

<cky>(define point (struct (x : uint8) (y : float)))

<cky>(define bs (array point 5))

<cky>Also would use keyword arguments for setting field values.

<taylanub>remaining portable is a concern for that library, so no keywords... though struct keys can actually be any object `eq?' handles, so in Guile-only code you could use keywords.

<taylanub>I think macros shouldn't be overused where procedures do fine. and I especially dislike abuse of s-expressions like (x : foo) to be honest.

<taylanub>.oO( wonder if I should rename vector to array, then drop the bs: prefix on the compound types )

<taylanub>but nah, array means something different in Scheme/Guile

<taylanub>might want to rename vector to bsvector or so and then drop the prefix on the others though; I don't apply the prefix consistently; I happened to develop an ad-hoc convention of using it only for compound descriptor types but not primitive ones like int and float

<taylanub>meh, bikeshedding

<cky>Lol.

<cky>Portability isa fool's errand, anyway: http://stackoverflow.com/a/11066232/13

<cky>taylanub: For example, look at my implementation of SRFI 28 (most recently) or SRFI 41 (less recently) that are in the Guile tree. Both of those are highly non-portable, and tailored specifically for Guile.

<taylanub>cky: I have implementations of both in R7RS :)

<cky>The _interfaces_ they provide allow people to write portable code, but the _implementations_ are absolutely not portable.

<taylanub>well, stealing the reference implementations

<taylanub> https://gitorious.org/taylan-scheme/srfi/ quite a few SRFIs can be implemented in portable R7RS

<cky>If you read my post, you'll see that my opinion is that reference implementations are often non-optimal, to be used only if there are no alternatives.

<taylanub>and bytestructures is fine with pure R7RS too since it's so "abstract," though all numeric types other than uint8 are in an R6RS extension because R7RS only has bytevector-u8-ref/set!

<davexunit>cky: I'm with you re: portable scheme

<taylanub>the biggest lacking things are proper system interfaces for POSIX and such. SRFI-106 has sockets though, and one implemented PostgreSQL bindings in R7RS plus very few SRFIs including 106: https://github.com/ktakashi/r7rs-postgresql

<cky>Nice. :-)

<taylanub>I think the biggest thing holding standard Scheme back from the ability of writing ""real"" code is the pessimism of everyone on the RnRS. the R6 vs. 7RS situation really sucks and is sad, and it would be amazing if some of the older experts joined the standardization process as Wingo &co. wished, but I see no reason not to standardize typical interfaces that you see in any ""real"" language;

<taylanub>defining those interfaces seems to be, for the most part, drudgery.

<taylanub>maybe I'm mistaken, but I don't see why we should need Scheme implementation experts like say William Clinger when merely defining some POSIX APIs...

<taylanub>(on the other hand, the discussion and outcome on R7RS's `current-seconds' shows us how beneficial it is to have some domain experts. even a seemingly trivial thing like getting a unix epoch timestamp comes out to be highly complicated and a bad idea to follow what all other languages do...)

<cky>Hahahaha, I was part of that discussion. :-)

<cky>(Re TAI vs UTC.)

<cky>I <3 that Schemers care about Doing The Right Thing.

<taylanub>ah right, I seem to remember some posts from you when I read the archives :)

<taylanub>cky: by the way, what kind of circular list that isn't supported in std Scheme is needed in SRFI-41's stream-constant?

<taylanub>maybe I should just look at your implementation of it

<cky>taylanub: In most Scheme implementations, you can make a circular list by finding the last pair of the list and set-cdr! it back to the loop point.

<cky>However, Racket pairs are immutable and do not support set-cdr!.

<dsmith-work>Happy Friday, Guilers!!

<cky>dsmith-work: :-D

<cky>taylanub: So in Racket, its SRFI 1 circular-list is implemented using a totally different way.

<taylanub>cky: but R7RS '(scheme base)' pairs are mutable, so the SRFI-41 implementation can do that just fine .. I'll later do that then.

<taylanub>perhaps the SRFI-41 ref. impl. was written by a Racketeer :)

<taylanub>(I mean, there was no R7RS then, but R5RS pairs are mutable too, so...)

<paroneayea>davexunit: https://identi.ca/cwebber/note/ZGIU4NykTQ-wVeQJGqDo6g

<paroneayea>I just replied as such to the list, but no response yet

<paroneayea>er

<paroneayea>bleh

<paroneayea>it doesn't show up in mailman's archives yet, I meant

<davexunit>:(

<davexunit>I really like texinfo

<davexunit>nicferrier wrote an info reader in javascript

<davexunit>something like that would make texinfo more web friendly

<davexunit>wtf is asciidoc

*davexunit looks

<paroneayea>I've never used it, and I don't remember it being used

<davexunit>if we were to switch, why not pick a format that other people actually use?

<davexunit>I feel like this isn't thought through. ESR has strange preferences himself. his push for git made sense because it's clearly the winning DVCS, but this makes much less sense.

<paroneayea>yes I agree

<dsmith-work>What? What's so wrong with texinfo? It's great. Prettier that LaTeX too.

<dsmith-work>Lately, I've been writing stuff in org-mode and exporing to something else.

<dsmith-work>So maybe that's the point...

<paroneayea>davexunit: mind if I steal your phrasing?

<paroneayea>in a reply to ESR

<paroneayea>on "clearly the winning DVCS

<paroneayea>"

<davexunit>go for it.

<davexunit>look at me, speaking to ESR by proxy. :)

<davexunit>ESR's argument: young people are too dumb to figure out how to read docs that aren't in a web browser

<dsmith-work>Bah

<davexunit>wellp, here we go again.

*davexunit grabs popcorn

<paroneayea>davexunit: I agree that emacs' manuals' HTML output should be better

<paroneayea>sure!

<paroneayea>I think that should happen across GNU

<paroneayea>vanilla texinfo HTML output looks *terrible* by today's standards

<paroneayea>but I don't think we need to throw out info in the process, and I think asciidoc doesn't make a lot of sense

<paroneayea>btw, I like info better than I like texinfo ;)

<davexunit>yeah, texinfo should come with a pleasant looking stylesheet for html conversion

<davexunit>that would go a long way

<paroneayea>I was saying the same to johnsu01 at seagl's after party

<davexunit>and then nicferrier's javascript info reader could be used for a more web 2.0 interface.

<paroneayea>low hanging fruit for GNU being more modern could be to improve its web presence, even just with improving styling

<dsmith-work>Bare info files look batter and are more readable than bare html files.

<paroneayea>so I am 100000% agreed there

<davexunit>gnu.org needs to be completely revamped, too.

<paroneayea>dsmith-work: while I love info files in emacs, there's no reason not to improve our HTML output.

<paroneayea>and a lot can be gained.

<dsmith-work>But everyone has a browser. Except when you don't.

<davexunit>too bad there's resistance to overhauling gnu.org... too much technical debt and people that won't admit that apache server side includes are bad bad bad bad bad

<davexunit>and hosting it all in a CVS repo is even worse.

<bipt>i'm really skeptical that rms would approve a switch from texinfo to asciidoc. maybe esr meant using asciidoc for files that are currently plain text?

<bipt>the lilypond manuals look a lot better than the default texinfo output: http://www.lilypond.org/doc/v2.19/Documentation/notation/note-heads.html#special-note-heads

<davexunit>org-mode would make more sense in that case.

<bipt>yeah

<dsmith-work>Yes!

<davexunit>yeah, that manual looks decent.

<davexunit>still dated looking, but better than default.

<paroneayea>bipt: it looks better, but it's not nearly as nice as say

<paroneayea> http://hy.readthedocs.org/en/latest/ or http://mediagoblin.readthedocs.org/en/v0.7.1/

<davexunit>slap bootstrap onto texinfo's html output

<paroneayea>though notably

<paroneayea>sphinx at least *has* info output

<paroneayea>as an option

<paroneayea>and really

<paroneayea>this is a cosmetic issue more than anything

<davexunit>I don't like reading non-info manuals because I can't press the 'i' key and jump write to the keyword I'm looking for.

<paroneayea>I do love the keybindings of info

<paroneayea>and the offline reading of it

<davexunit>hmm, hearing a lot about Julia these days

<paroneayea>I have continued to wonder, since Julia supports macros, how much a julia-like language could work with guile

<paroneayea>just as a kind of language sugarcoat, similar to what ArneBab is doing with wisp

<paroneayea>but i actually know little of it

<paroneayea>other than that it's built on top of racket

<paroneayea>and that it looks like python, and has macros

<davexunit>oh it is? didn't know it used racket.

<paroneayea>yup

<davexunit>all I know is that there's an office at MIT with a julia logo on it :)

<taylanub>you can pry sexprs+paredit from my cold, dead hands ;)

<paroneayea>taylanub: nobody says you have to lose sexprs even if a sugarcoat language lived on top of guile!

<taylanub>code written in that language will not be sexpr code... I don't like things like SRFI-110 and Wisp for this reason. I think we should just teach people to use Paredit or similar. I also got very used to the plain visuals of lisp code and doubt the parentheses are a significant issue even in the extreme cases like 'let-values' usage. I think it's simply a matter of getting used to it, say in a

<taylanub>week or two.

<paroneayea>well if that's true, then peolpe will use sexprs anyway, and you have nothing to worry about :)

<paroneayea>people

<taylanub>we need more people educating them for that. currently there's a lot of memetic FUD surrounding sexpr syntax.

<paroneayea>;p

<taylanub>"Lots of Irritating Silly Parantheses" and all. if meant as a joke then OK, but people who don't know lisp actually take that serious :\\ and well, I can understand that when they don't use paredit.

<dsmith-work> http://xkcd.com/297/

<taylanub>I've seen that before but I think it has a culture reference I'm missing :P

<dsmith-work>!!

<dsmith-work>taylanub: star wars

<taylanub>what does he hand him over in the original?

<dsmith-work>lightsaber

<taylanub>could've guessed :P

<taylanub>there seems to be a renewed Star Wars craze; I fell right in the spot where it wasn't all that popular. saw some of the movies once or twice on TV as a child...

<fangism> http://xkcd.com/224/

<dsmith-work>Bah perl

IRC channel logs

2014-12-05.log