***fangism is now known as fangism-hungry
<mark_weaver>nalaginrut: you need to use the guard syntax (TEST GUARD => EXPRESSION) <mark_weaver>as the manual says, GUARD is called as if it were the CONSUMER argument of call-with-values. <mark_weaver>((values 1 2) (lambda (x y) (= x y)) => (lambda (x y) (cons x y))) <mark_weaver>so both GUARD and EXPRESSION evaluate to procedures that take as many arguments as there are values returned by TEST. <mark_weaver>GUARD returns a boolean to tell whether this clause should be used. <nalaginrut>oh, I made a mistake, seems the pred is the guard <mark_weaver>normally, the TEST itself is the guard. but if TEST returns multiple values, how should it be tested? <mark_weaver>that's why you need GUARD if there are multiple values. <nalaginrut>if TEST is ok then return two values to the receiver, since the receiver need two args <mark_weaver>I'd like to change the HTTP date parser to accept UTC as the zone offset. it's not just a few isolated websites. there are transparent web proxies out there that change the GMT to UTC. just the other day, someone trying to use Guix from his school was out of luck because he was behind such a transparent proxy. *nalaginrut hope this change won't effect Artanis <mark_weaver>guix is being hurt by our unusually strict http code, where just about every other web client out there is quite permissive. <mark_weaver>nalaginrut: please think before you object. don't just object to any change at all. <mark_weaver>well, okay, I guess you weren't objecting, just being nervous :) <unknown_lamer>because dealing with typed arrays and doing math on them is ... not fun <unknown_lamer>I've got a basic matrix math library for doing what I need to build projections etc. in gl, but ... ugly, slow, loses type information <wingo>mark_weaver: sure, UTC sounds fine to me <wingo>sorry for the stop energy before :) <mark_weaver>wingo: thanks! no problem, I respect strictness and usually advocate for it, but in this case I don't think it buys much and is a lost cause :) <unknown_lamer>also, having {u32,f32,...}vector->bytevector and the reverse would be nice, since it can be done in C by just sharing the arrays. Maybe even a make-array-from-vector ? (bad name, I imagine) <wingo>unknown_lamer: u32vectors are bytevectors <wingo>all srfi-4 vectors are bytevectors *wingo agrees with Mao: "no investigation, no right to speak!" :) <unknown_lamer>you can *use* them as uniform vectors, sure. But you can't tag them as such and have them print nicely <unknown_lamer>which is pretty useful when you're building a ton of 4x4 matrices <wingo>unknown_lamer: have you looked at the srfi-4 implementation? <wingo>make-srfi-4-vector tags a bytevector as being a u32vector <wingo>or rather creates a bytevector that is a u32vector <unknown_lamer>I want to be able to take a bytevector returned by opengl and have it properly typed as a uvec <unknown_lamer>so that I can print it out, and not feel dirty about disjoint types doing bad evil non-typesafe things <unknown_lamer>I get the impression from doing SML that having a value that can be several disjoint types at the same time effectively prevents static type checking <wingo>unknown_lamer: yes, it can be an issue <unknown_lamer>but, ignoring the bytevectors, stuff, how about subvector for grabbing portions of a uniform vector, and something to create an array backed by a uniform vector from scheme (given you can already do it in C...) <wingo>so, that's funny that you want subbytevector :) <wingo>i don't know why you want static type checking -- for perf or for correctness? <wingo>if the former, aliasing kills many optimizations <unknown_lamer>I got used to SML telling me I was being bad. And SBCL even. <wingo>which is what subbytevector is <wingo>anyway, out current bytevectors do have alias semantics *nalaginrut wants subbytevector/shared... <wingo>would be best to use a standard subbytevector name if there is one, is mostly my opinion there <unknown_lamer>there is none, chicken looks like the only one to implement it <wingo>if you're not implementing a sharing semantics you can do it in your own code <wingo>copying pieces of bytevectors is rarely what you want to do... <unknown_lamer>I'll just implement what I'm thinking about locally and use the ffi for great evil to grab the _take procedures <gjanssens>When I use scm_from_locale_string to convert the C string "€ 100,00" to guile <gjanssens>this works fine on guile 1.8, but results in "? 100,00" with guile 2 <gjanssens>I also tried to use scm_from_utf8_string on guile 2, but the result is the same <mark_weaver>is it a C string literal that you're converting, or is the string coming from somewhere else? <gjanssens>my locale is set to a mixture of en_US.utf8 and nl_BE.utf8 <gjanssens>I'm not sure which LC_ setting is exactly relevant here <wingo>gjanssens: are you trying inside gnucash? does gnucash call setlocale? <wingo>mark's question is relevant too :) <mark_weaver>if it's a C string literal, then you should be using scm_from_utf8_string. <wingo>gnucash is venerable, it could have legacy encodings in it somewhere :) <mark_weaver>if the string is coming from somewhere else, most likely you want scm_from_locale_string. *wingo chooses adjectives carefully ;) <mark_weaver>well, it doesn't matter what encoding the source code is written in. what matters is the execution character encoding, and modern compilers generally use UTF-8 for that. <mark_weaver>(for some time, I thought that the source code encoding was the relevant thing, but it turns out I was mistaken about that) <gjanssens>It turns out GnuCash is littered with setlocale calls... <gjanssens>Does each call affect the whole of the application, or only the function it is called in ? <wingo>each call affects the whole application -- locale is a per-process state <gjanssens>Ok, that will probably need cleaning up then <wingo>usually you want to just (setlocale LC_ALL "") once in the beginning of the program <gjanssens>Except there are some parts in GnuCash that are only working in a specific locale <gjanssens>So whenever that is called, the locale is set to German <gjanssens>what is the function in scheme to change locale ? <wingo>gjanssens: setlocale; it may or may not be in 1.8 however, i don't recall <wingo>anyway you run into those strange string issues in 1.8 <wingo>as 1.8 strings are byte strings :( <wingo>gjanssens: sure, i understand it's working for you in 1.8 right now, but i think it's almost by accident <wingo>working with non-ascii strings in 1.8 always involves some sort of pun between byte strings and the current locale <mark_weaver>2.0 actually deals with character encodings in a sane way. but it needs to know what encoding to use whenever it's doing I/O or converting to/from byte arrays. <mark_weaver>if you don't set the locale, then it assumes ASCII only. anything else will be an error, which by default becomes ? <wingo>gjanssens: see "** Unicode strings" in the NEWS file for the details <mark_weaver>to do non-ASCII I/O in 2.0, you need to either set the locale, or explicitly tell it what encoding to use for the port or conversion. <gjanssens>anyway the string I'm trying to convert is composed by other strings using the g_stpcpy function <mark_weaver>the 1.8 way of doing things sometimes works fine, but in many cases it will break completely. for example, if a string comes from a C string literal and then you try to write it somewhere that's expecting an encoding other than UTF-8, it will simply do the wrong thing. <mark_weaver>likewise if you read from one port or file that's in one encoding, and then write somewhere that uses a different encoding. <gjanssens>mark_weaver: that will probably explain why our reports are not working well for non-utf8 locales <mark_weaver>and of course, if you try to iterate over characters or ask for the length of a string, you'll get the wrong answer in 1.8 if there are any non-ascii characters present. <wingo>gjanssens: one possibility to consider is that somehow your string is correctly converted to scheme, perhaps because you used scm_from_utf8_string -- but it can't print correctly because your current locale can't display all characters <wingo>that is probably what is happening <mark_weaver>right, I think that's very likely. is the string coming from a C literal? <gjanssens>you mean the locale that scheme assumes it should use ? <wingo>so make sure that whatever port you are printing on has its "port-encoding" set correctly <wingo>yes perhaps this isn't a locale thing but a port encoding thing <gjanssens>and by the lack of an explicit setlocale call, that would be ascii ? <mark_weaver>you can set the encoding explicitly for each port if needed. you can also set a default port encoding. otherwise it will use the encoding corresponding to the locale. <mark_weaver>and yes, if the locale is not set, and you don't specify the port encoding in some other way, then it will assume ASCII only. <gjanssens>If I understood correctly, guile runs in a separate thread <gjanssens>so if I set the locale properly in one thread, the other threads will inherit it as well ? <mark_weaver>iirc, there are some platform-specific APIs around that allow setting the locale for a single thread, but nothing widely supported. <lloda>unknown_lamer: if you need slicing arrays, please have a look at guile-ploy <lloda>it has a (from) form for tensor slicing <lloda>so you can do (from A indices-0 indices-1 indices-2 ...) <wingo>lloda: apologies again about not getting to your array stuff, it is #1 on my list <lloda>for guile-ploy, it's not perfect, but please have a look before writing your own wrappers <lloda>one thing I've been having trouble with is how do do settable regions <lloda>like in numpy one would do A[...] = B ... <lloda>when A[...] is itself a shared array, it's not a problem <wingo>can you fill in the ... ? :) <lloda>then A[0:4] or A[3:9] are also arrays <lloda>only the strides etc. change <lloda>(from A (range 0 4)) or (from A (range 3 9)) <lloda>and those return a shared array, just as in numpy <lloda>but let's take something like <lloda>the result is an array, but not a shared array sharing storage with A <lloda>now this resuts in a fresh array <lloda>but in numpy (and in every array language) you can do <lloda>A[[3,9,2,4]] = array-of-four-elements <lloda>so I'd need (from A #(3 9 2 4)) to return some kind of settable object *nalaginrut is glad to see gnutls included guile binding in natural <wingo>lloda: right now it would return a flat vector, no? <wingo>does guile-ploy use goops at all? (just wondering) <lloda>Would that be the only way, you think? <wingo>goops can be a nice solution when you have N-ary operations on M types <wingo>to avoid combinatoric explosion, while still getting fairly efficient dispatch <wingo>but it's also complicated and hairy <wingo>so if you can avoid it you probably should :) <lloda>that's the vibe I was getting from goops :-( <wingo>so you are thinking some (assign! (from A #(3 9 2 4)) foo) operator? <unknown_lamer>lloda: I think you just saved me from pulling more of my beard out! <unknown_lamer>doing matrix math with vectors and arrays is ... not very convenient <wingo>yeah, i like many things about goops but it never pays off for me <unknown_lamer>and dang opengl had to go and remove gluLookAt and all of the matrix functions forcing me to write this *first* <unknown_lamer>I am torn about goops, since I was a paid clos wizard for a while... but then I used SML for a while and OO is Bad (tm) <unknown_lamer>merging type dispatch, records, ... into one clusterfuck of a concept <lloda>wingo: right know you CAN do (array-copy! (from A ...) foo), but only for some kinds of ... ideally it should work for any. <lloda>unknown_lamer: I hope it helps, it's rough but I find it useful <wingo>probably makign array-copy! dtrt is best <wingo>so ok i'm with you up to here in your thought process i think :) <unknown_lamer>of course, I'm thinking about making a <matrix> class and ... <unknown_lamer>wingo: guile-figl was becoming guile-opengl and an official gnu project, right? <wingo>and i guess array-copy! is a hairy array-specific thing, and it should be general instead, is that the problem? <wingo>ok. well i totally agree with you anyway :) <wingo>surely it is possible to fix :) <unknown_lamer>longer term, I'm wondering how hard it would be to try and support opengl 3.3 core profile and opengl 2.1 at the same time (since mesa has declared they will never support compatibility contexts, blech) <unknown_lamer>the annoying part of that is that jwz implemented most of OpenGL 1.5 in terms of OpenGL ES 2 in a single weekend... <wingo>i know it's nice to use the new thing, but 2.1 + extensions is pretty good <unknown_lamer>there's a chance opengl 2.1 will just stop working within the decade <unknown_lamer>given how fickle all of the graphics stack people seem to be <unknown_lamer>"your five year old hardware is useless and should be recycled!" <wingo>i doubt it -- at least the opengl es 2.0 stuff will be around forever, now that it's on the web... <wingo>which makes me wonder if it's possible to use angle to do gles on windows, humm <lloda>wingo: not, because it would mean array-copy! doing something totally different. After all (from A #(1 4 3 9)) can't be a shared-array and also be settable. A different name like assign! is probably better, I had reserved set-from!... <wingo>angle is an opengl es 2.0 -> direct3d thing used in web browsers <unknown_lamer>what I really like is how my hardware doesn't support opengl es 2 or 3.3 and yet webgl works <wingo>unknown_lamer: firefox uses angle <lloda>gles on the desktop would be great, bye glut, bye glx... I think. I still use glut... <wingo>i don't know much about naming but i hate those names <lloda>there's trouble with array-copy! and array-map!, they have different conventions for shape agreement (!) <lloda>and what's worse, this is documented (!!) <lloda>that's why the arguments of array-copy! are inverted in the call to ramapc <lloda>I actually wrote tests to enforce that, but I'd like to get rid of the difference <wingo>lloda: probably the only way to change is to make a new interface and deprecate the old, unfortunately <lloda>yes, and put everything in a module. But I thought it would be best to fix the current behavior, at least, before bulldozing it <lloda>unknown_lamer: I have quaternion functions, but they're implemented in C <unknown_lamer>just make the compiler spit out sbcl vops and use sbcl for the heavy lifting, duh <unknown_lamer>lloda: you don't happen to have the code lying about in public do you? (I don't need them *now*, but I'm going to end up having to implement them eventually for matrix generation) <lloda>I can publish a half-assed numpy version, if that would be useful to you <lloda>it's not as general as I'd like <lloda>the idea is that if you do (rotor-apply rotor vectors), this would be rank 1 1 <unknown_lamer>maybe I can publish my crappy matrix code and opengl demos and someone else will use them for complicated things and write those bits <lloda>unknown_lamer: sorry about that <lloda>there's an idea in guile-ploy, where you'd just write the operations on vectors (say, quaternion-quaternion-multiply takes two 4-element vectors) and ply gives you broadcasting. But it's too slow. It doesn't have to be, but... <unknown_lamer>I've been having good results with mark_weaver's NaN boxing thing <unknown_lamer>wingo: I was able to get your particle demo up to hundreds of thousands of particles on my fancy eight core machine <unknown_lamer>whereas before the gc time just killed everything (when you gc for a second every second you know) <wingo>unknown_lamer: not at 60fps, i would think <wingo>on my 8-core machine i got up to 11k particles or so at 60fps <wingo>with the free radeon drivers <wingo>ah, you used the nanboxing patch, neat <unknown_lamer>I really wish I could use OpenGL 4 geometry shaders though... <unknown_lamer>pass in the x y z and velocity. let the card generate the quads (well, pair of triangles) <lloda>floats are slow, actually operating on #f64(...) is slower than #(...) because there's more type dispatch involved in each operation. I see how nan-boxing could help with that... <unknown_lamer>(depressingly enough because XScreenSavers that use XFillRect() or whatever were obnoxiously slow, thanks to the radeon driver not optimizing that) <lloda>the array operations (array-map!, etc) all do type dispatch per element, so they are all very slow. Only some cases are treated specially and are faster. <wingo>lloda: i think f64 vectors are slow because it boxes when it access the vectors <wingo>whereas guile vectors store the boxed value <wingo>that was the case in racket too for a long time <lloda>type inference would be huge for arrays <mark_weaver>TaylanUB: I haven't published my nan-boxing patch yet, so no one can answer the question except for me (and maybe unknown_lamer, who I took pity on because he was so eager to try it :) <mark_weaver>TaylanUB: to save me the trouble of reading that article again, what "issues" are you referring to? <mark_weaver>unknown_lamer: it would be trivial to add support for quaternions using GOOPS. the core numeric operators are all extensible that way, without hurting the efficiency of those ops on the core types. <mark_weaver>I have multiple implementations of quaternions lying around; I don't remember if I hooked them into goops or not. <TaylanUB>Let's see .. 1) Portability, 2) the overhead of passing doubles everywhere on 32b architectures, 3) more false positives in the BDW-GC. <TaylanUB>Hrm, maybe s/32b architectures/embedded architectures/ ? I'm not sure. <mark_weaver>well, my patch currently only implements nan-boxing on arches where pointers are 64 bits. <mark_weaver>however, I'd like to add the ability to use 64-bit SCM values on 32-bit arches. but that's a slightly harder job, since there's a lot of code around that implicitly assumes that sizeof(void*) == sizeof(SCM) <TaylanUB>Oh, the GC issue also only applies to 32b! <mark_weaver>false positives in BDW-GC: that's probably not an issue, because the (biased) exponent field is usually large, and in the top bits, and no actual addresses have such big values yet. <TaylanUB>Right, it only says it's a problem on 32b. <mark_weaver>as for portability, there's one hard issue there: with nan-boxing, we can't support virtual addresses larger than 50 bits <mark_weaver>currently, 64-bit machines typically only support a 48-bit address space, but 56-bit address spaces probably aren't very far off. <wingo>the shape of the 48-bit address space can also vary fwiw -- it is different on sparc <mark_weaver>at which point we'd either have to ditch nan-boxing altogether, or artificially limit the heap to addresses where the high bits are all zeroes (or ones) <mark_weaver>well, some systems use the high addresses in addition to the low addresses. <mark_weaver>my current nan-boxing patches handles high addresses. <mark_weaver>but yeah, when the address space becomes bigger than 50 bits, we're just screwed. <mark_weaver>and binaries compiled today could be used on a 56-bit system tomorrow, so it's dicey. <mark_weaver>by rotating the bits, and assuming the low 4-bits are zeroes on heap pointers, we could perhaps get 53-54 bits of addresses, but no more. <mark_weaver>in summary, I don't think nan-boxing is a good default choice, but I think I'd like to add it as a compile-time option, for those who need better floating-point performance in the short term. ***ijp` is now known as ijp
***fangism-hungry is now known as fangism
<TaylanUB>Wah, amazing seeing a Guile+SDL+OpenGL based game "just work" on OpenBSD. :P <ijp>sign of the end times, I tell you <TaylanUB>Unfortunately SLAYER seems to embed Guile instead of extend. (Or maybe the executable is just a small wrapper to prepare things, I dunno.) <davexunit>when I was thinking of starting work on guile-2d, slayer was brought up and I remember it having much different goals than I had in mind. <TaylanUB>Indeed, it's a multimedia/game system too so you'd expect similarities ... <saul>Has anyone here tried the Boot-To-Guile demo QEMU image? Is there a text editor provided (I can find one)? <civodul>saul: that was just an initrd, so no text editor, no shell, just a REPL <civodul>in the meantime we've gone a bit further though :-) <civodul>#guix is a fine place if you want to discuss these things ;-) *wingo running into strong icache/dcache effects; +/- 20% or so