IRC channel logs

<ArneBab>it already helped me to refine the python-based preprocessor: now it can actually turn the unfinished wisp-based preprocessor into proper scheme

*ArneBab really got surprised by char literals: #\\\\( ← completely broke my bracket parser - now fixed :)

*ArneBab is a Pythonista by trade, but finds scheme really interesting

<mark_weaver>ArneBab: FYI, although working on strings directly with 'string-ref' is currently faster, in the future it might very well be faster to use string ports. although if master continues to lock mutexes on all port operations, maybe that won't be true :-/

<sneek>Welcome back mark_weaver, you have 2 messages.

<sneek>mark_weaver, cky says: Congrats on passing GCJ Round 1A!

<sneek>mark_weaver, cky says: My solution uses the same solution approach as yours, but as you can see, you didn't need to use the formula as a starting "guess" value; it turned out to be correct every time. (At least for Racket.)

<ArneBab>mark_weaver: oh, thanks!

<mark_weaver>ArneBab: FWIW, I wouldn't choose one or the other based entirely on efficiency. I would also think about what results in the best code.

<ArneBab>then I think I’ll firstoff keep the ports I already did, because they provide a simpler interface: They show explicitely that the function is intended to only read the function once.

<ArneBab>mark_weaver: besides that: I wanted to ask you a week ago, what you meant by an uphill battle for guile.

<ArneBab>mark_weaver: To me it feels like guile is pretty well setup

<ArneBab>(well situationed)

<mark_weaver>well, I mean uphill compared with other extension languages such as python or lua that most people prefer.

<mark_weaver>but in the scheme world, I agree that guile is pretty well positioned. and of course the continued support by RMS is very helpful.

<wingo>heya mark_weaver

<mark_weaver>hi wingo!

<mark_weaver>wingo: yeah, it occurred to be recently while thinking about my planned work on strings and ports in master, that string ports could be made *very* fast (and I want them to be), but if our contract with users includes mutexes on port operations, they will be a *lot* slower.

<ArneBab>mark_weaver: ah, ok. That sounds quite true, though I think every language starts with that before getting big :)

<mark_weaver>wingo: one compromise that comes to mind is to provide an optional module that exports mutex-protected versions of the port operations.

<ArneBab>mark_weaver: the one thing I missen in guile was a simple (and directly visible) tutorial how to use it as scripting language.

<ArneBab>it’s pushed very heavily as extension language, but using it for simple scripting is quite tempting, too.

<mark_weaver>ArneBab: I definitely agree that we need better tutorials.

*bubu^ like guile as scripting language !

<bubu^>It is a nice replacement to weird and strange syntax bash script

<ArneBab>…but someone has to write them, I assume (that’s the binding factor most of the time…)

<bubu^>when you want to things a bit bigger than 5 lines

<bubu^>+do

<tupi>ArneBab: look at the mailing lists, there has recently been a couple of good scripting examples, search for "Guile 100"

<bubu^>yet I don't really use guile that way :(

<ArneBab>oh, nice!

*tupi writes his scripts, all of them, using guile

<ArneBab>bubu^: I currently mostly use Python that way, but I started using guile instead of python as simple calculator :)

<bubu^>tupi, maybe you could make a (short) summary of all the "good tips" you use the most often in your scripts ?

<bubu^>so that there are some easy to reuse and adapt basic templates

<ijp>mike has been quiet on the guile 100 front recently

<tupi>bubu^: you'll find that in the examples i just refered to. i don't use templates

<mark_weaver>to be honest, although I really like Mike's guile 100 initiative in general, I strongly disliked his most recent one (php-style guile). I wonder if I wasn't alone, and if he became discouraged because of that.

<ijp>I keep meaning to go through the ones submitted, and start picking nits

*tupi too

<tupi>one could lead to a bug actually, but didn't write yet [too bad, i should, of course]

*tupi really liked mike's idea too

<mark_weaver>cky: thanks. yeah, I looked at your solution and noticed that you didn't do the final adjustment loop. indeed, it wasn't needed, but at the time I was a bit unclear on that, and it was easier to write a few more lines of code than to convince myself it was safe :)

<mark_weaver>cky: I really should have been able to get C-small done too. I regret my policy of ignoring the small problems and focusing only on solving the large problems.

<alexei>#define EXPORT(name, req, opt, rst, func) (scm_c_define_gsubr (name, req, opt, rst, func), scm_c_export (name, NULL))

<alexei>do I reinvent the wheel here?

<alexei>Hi!

*alexei in RPN mode

<dsmith-work>alexei: Look at the snarfing macros

<alexei>ok, thanks! I am not ready yet to re-work the build procedure.

<wingo>okeydoke, let's see if i can finally get rtl functions to disassemble

*stis crosses fingers :-)

<stis>err, holds the breath

<stis>heya mark_weaver:

<mark_weaver>hi stis1

<mark_weaver>wingo: sounds great! :)

<stis>mark_weaver: do you think that we should try to extend ice-9 match for arrays?

<stis>or even fro strings and bytevectors?

<civodul>it already works for strings

<stis>civodul: cool, then for byte vectors and generalized vectors!

<stis>Hi civodul:

<civodul>it already works for vectors

<civodul>:-)

<mark_weaver>actually, byte vectors works as well as strings do. i.e. you can match an entire bytevector or string.

<civodul>ah, right

<civodul>heh

<mark_weaver>what you *can't* do is match a bytevector or string pattern that contains symbols, of course.

<stis>Cool, then the quirq was just the reader for that case!

<stis>mark_weaver: yeah!

<mark_weaver>but support for arrays should be quite doable.

<stis>Yeah, I'm quite fluent in ice-9 match and could implement that if you like!

<mark_weaver>sure, post a proposed patch and I'd be glad to take a look.

<stis>My concern is to decide about the interface though.

<stis>ice-9 match is really not that easy to extend without breaking code!

<mark_weaver>also, if we supported array patterns, you could use those to match against strings, bytevectors, bitvectors, etc.

<mark_weaver>the interface? wouldn't it just be to allow arrays as patterns?

<ijp>right, I don't see why this needs to break any code (in theory)

<stis>Ok, you mean that again they are fast tracked reader macros!

<mark_weaver>e.g. (match #2((1 2)(3 4)) (#2((a b)(c d)) (list a b c d))) => (1 2 3 4)

<stis>Then it's not a problem!

<mark_weaver>no, there's no reader macro involved here.

<stis>#2 is not a reader macro?

<mark_weaver>oh, hmm. we might need to add support for arrays to psyntax though.

<mark_weaver>no, #2(...) is core read syntax for arrays.

<mark_weaver>just like #(...) is standard read syntax for vectors.

<stis>Didn't know of that concept, can explain why I'm so tefloniac about these things :-)

<mark_weaver>i.e. reading #(a b c) returns a vector with three symbols, and reading #2((a b) (c d)) returns a 2d array with symbols.

<ijp>tefloniac??

<mark_weaver>but yeah, I see now that we couldn't do this entirely in (ice-9 match). we'd need to extend psyntax to support array patterns (alongside list and vector patterns)

<dsmith-work>stis: tefloniac ?

<mark_weaver>yeah, I don't know that word either :)

<ijp>my mind pirspicuineses at the word

<dsmith-work>ijp: Phthhh

<stis>the consept is slipping my mind like butter in a teflon pan

<ijp>that was just a grab bag of syllables, before you all go googling

<stis>At least teflon is what we say in sweden, Thought it was international!

<mark_weaver>we call it teflon in the US as well. it's a trademark.

<mark_weaver>(PTFE, i.e. Polytetrafluoroethylene, is the generic term)

*stis wishes that we standardized more at an extensible matcher

<stis>but that would of cause not be as convinient as ice-9 match for most cases!

<mark_weaver>I sometimes consider rewriting (ice-9 match) in applicative style using 'ck'.