IRC channel logs

<mark_weaver>unknown_lamer: patches welcome!

<unknown_lamer>I must resist the urge to derail from writing an opengl program :(

<unknown_lamer>I'm already suspecting I'm going to end up writing an sexp notation for GLSL

<unknown_lamer>(luckily, I've had to do a similar thing before so I don't have to spend ages figuring out how to write a compiler again)

<mark_weaver>that would be great!

<unknown_lamer>I just hate opengl 3.x >:O

<unknown_lamer>stupid core/compatibility context thing, and mesa refusing to support compatibility for 3.x

<unknown_lamer>this wouldn't be a *huge* deal since you can get by with only using stuff in the OpenGL 3.3 core profile in OpenGL 2.1

<unknown_lamer>... except they also removed support for all old GLSL versions so you have to write two sets of shaders

<madsy>What? OpenGL 3 and 4 is awesome

<unknown_lamer>not if you want to support OpenGL 2.x (or, worse, 1.x) at the same time

<unknown_lamer> http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/

<madsy>Maybe not, but why would you want to?

<unknown_lamer>"Specifically, if you were involved in the OpenGL specification between 2003 and today, you are an idiot."

<madsy>At some point you have to cut off legacy

<unknown_lamer>my laptop is only 3.5 years old and only supports opengl 2.1

<unknown_lamer>also what if you e.g. want to write an xscreensaver hack that runs on machines going back to the late 90s (not too unreasonable, since most of them were written in that era)

<madsy>My previous laptop was 7 years old (I just got a new one) and it supported OpenGL 3.3

<unknown_lamer>I have a weird core2duo 10W chip + GS45 (x4500mhd)

<unknown_lamer>gen4 doesn't do opengl 3.3 :(

<madsy>OpenGL 3.0 is about 7 years old now. It's about time to move on, if you ask me :)

<unknown_lamer>my real problem is that OpenGL 2.1 and 3.x would be compatible, if it weren't for the arbitrary GLSL deprecation

<unknown_lamer>the changes are largely mechanical, the compiler could handle them

<madsy>It's not arbitrary at all

<unknown_lamer>instead poor me is thinking about how I might abstract GLSL 1.2/1.3 and 3.3 differences...

<madsy>There are new keywords

<unknown_lamer>it's all for the ease of the graphics hardware manufacturers

<unknown_lamer>they don't want to maintain old cold

<madsy>Streamlined to be consistent with geometry shaders

<madsy>And integer support, etc

<unknown_lamer>right, but there's no reason why my current card shouldn't be able to run GLSL 1.2 programs

<unknown_lamer>afaict the only really sticky point is setting the fragment depth

<unknown_lamer>it's like GCC removing C89 and C99 support because C11 is out

<madsy>Comparing shading languages to programming languages is going a bit far, I think

<unknown_lamer>GLSL *is* a programming language

<madsy>And you can bet your ass that a modern GPU driver is much more complex than a C compiler

<unknown_lamer>I doubt that much, optimizing C is a pain in the ass

<unknown_lamer>ultimately the graphics driver is just shoving chunks of memory over to a card

<unknown_lamer>the GLSL compiler might be a bit hairy, but it can't be that awful

<madsy>That's a pretty ignorant statement. A GPU driver is extremely complex. And you have tons of legacy and extensions to take into account. And different state that can work together in different ways.

<unknown_lamer>... but they removed all legacy support

<madsy>Not in the compatibility extension. Which everyone still supports, except apple

<unknown_lamer>and mesa

<unknown_lamer>so by everyone you mean Windows :(

<madsy>huh?

<madsy>Microsoft haven't been involved with OpenGL in over a decade :)

<unknown_lamer>OpenGL 3.1 and later versions are only supported with the Core profile.

<unknown_lamer>There are no plans to support GL_ARB_compatibility. The last supported OpenGL

<unknown_lamer>version with all deprecated features is 3.0. Some of the later GL features

<unknown_lamer>are exposed in the 3.0 context as extensions.

<madsy>WGL extensions are made by IHVs

<unknown_lamer>and the only platform you use vendor supplied drivers on is ... Windows

<unknown_lamer>all that matters to me is the Free Software world, and /those/ developers decided that supporting the compatibility profile was too much work

<madsy>I'm using a driver from Nvidia as we speak. I'm on Ubuntu :)

<unknown_lamer>heathen

*unknown_lamer pretends he isn't using catalyst on his workstation

<unknown_lamer>perversely enough because of 2d performance problems with xscreensaver (rectangle filling on radeon is unoptimized in the free drivers and ... there goes half of the screensavers)

<unknown_lamer>"hang on while I do 1920x1080 pixel operations in sequence"

<madsy>So my point was, the GLSL 1.20 version was probably removed from the compatibility profile, because it was too much work to keep it around, and it wouldn't make much sense to enable that just for that profile and not the core profile

<madsy>Less code to maintain

<madsy>You can still make an OpenGL 2.1 fallback context if you really need one

<unknown_lamer>until they remove that :(

<madsy>Not going to happen. glXCreateContext/wglCreateContext is going nowhere

<unknown_lamer>I just want to write code against the subset of OpenGL 2.1 and 3.3 core profile that works, and have my shaders only do things that can be done in 2.1

<madsy>Too important for too many people

<unknown_lamer>GLX is /dead/

<unknown_lamer>I hear Ubuntu is switching to wayland in 2009

<unknown_lamer>;)

<madsy>Still

<madsy>That functionality is going nowhere

<unknown_lamer>meh, maybe I can just give up and embrace OpenGL 3.3 and use VirtualGL (amazingly enough it works with modern X!) from my laptop to workstation down the hall

<madsy>Or suddenly OpenGL would stop working on a lot of computers that depend on it

<unknown_lamer>GLX and OpenGL 2.1 support might actually be going away...

<unknown_lamer>I thought that Wayland/Mir used EGL instead of GLX, and then basically force all applications to use the context they pick?

<unknown_lamer>oh well, it'll be another decade before that transition happens so I give up for today

<unknown_lamer>now, the question is what to support from 2.1 in my changes to guile-figl... maybe just not do high level wrapping of all deprecated-in-3.0 functions?

<unknown_lamer>I thought they kept GL_POINT around and then I was sad to find out they didn't after I rewrote the particle system to use those intead of quads

<mark_weaver>is there a free implementation of OpenGL 3.0+ ?

<unknown_lamer>mark_weaver: yep! Mesa 9.2 supports OpenGL 3.3 on all platforms new enough

<madsy>Are you making a scheme-wrapper for OpenGL ad-verbatim, or do you make changes to the API?

<unknown_lamer>madsy: guile-figl already exists, and does a more or less verbatim wrapping

<unknown_lamer>with some high level stuff (e.g. (with-blah ...) whenever you have some strictly paired gl function)

<mark_weaver>does "support" mean that it's capable of doing the rendering itself, or is it only able to send commands to a proprietary system that does the rendering?

<mark_weaver>bbiab

<unknown_lamer>mark_weaver: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt seems to imply it works in swrast

<madsy>unknown_lamer: I went the opposite route. I'm embedding libguile into my application, which exposes some high-level graphics functions

<unknown_lamer>ah

<unknown_lamer>I am writing a tempest 2000 clone purely in scheme

<madsy>Ah, nice :)

<kurohin>unknown_lamer: for some reason it looks like my initialize method is not called. at least the (display ...) debug calls are not shown

<unknown_lamer>or maybe common lisp, because I don't have to fill out the GL bindings...

<unknown_lamer>but I want to believe damnit

<unknown_lamer>kurohin: are you writing to standard-output-port or standard-error-port? (they might just not be flushing and displaying)

<kurohin>using (display "some string") that usually flush directly when used in other places

<kurohin>unknown_lamer: http://pastebin.com/Ht5gnEWz the initialize I have problem with

<unknown_lamer>kurohin: http://unknownlamer.org/tmp/goops-custom-initialize.scm works

<unknown_lamer>I think you might need to return self from initialize, maybe not

<mark_weaver>unknown_lamer: you told kurohin to wrap ((next-method)) in double parens, but you didn't do that in your code.

<unknown_lamer>do what I meant to write not what I did write!

<mark_weaver>still, the 'display' should have worked (but it would be better to put "\\n" at the end of that string)

<unknown_lamer>kurohin: mark_weaver is correct, if you unwrap the next-method calls and bind rather than attempt to call the result your code Just Works (tm)

<unknown_lamer>the display works after I added a call to (newline)

<unknown_lamer>welp, time to head off for the evening

<kurohin>thanks for the help

<mark_weaver>in guile, stdout is unbuffered by default, so it should have printed immediately even without the newline.

<mark_weaver>(unless you set the buffering to something else)

<kurohin>still does not get any calls to initialize

<kurohin>starting to suspect that there is some problem with export-ing the function from the module I am in

<kurohin>no it works, don't know why

<mark_weaver>ah, you have to be careful with generic functions and module exports.

<mark_weaver>there should really be a writeup of this somewhere, so that I don't have to explain it every time.

<mark_weaver>basically, GOOPS has a "feature" that causes a huge amount of confusion. when you call 'define-method', or create a new class that implicitly defines methods such as accessors, it creates a fresh new generic function local to that module.

<kurohin>it seems that you cant only ,re (module foo) after having done changes, and expect it to work.

<mark_weaver>well, it automatically creates a fresh generic function if one is not already present in the current module.

<mark_weaver>the problem is that you can end up with multiple generic functions with the same name, in different modules.

<mark_weaver>and then, if you call the wrong one, it might not have the methods that you expected.

<mark_weaver>I wonder if that's what's going on here.

<kurohin>it fells like it could be something like that, will test ,in (foo) (make-instance ...) that should tell me if the problem you are describing is the problem I am having

<mark_weaver>hmm, well, 'initialize' is exported by (oop goops), so as long as you imported that before defining the new 'initialize' method, it should have been added to the right generic function.

<mark_weaver>wait, what are you doing to try to create the object?

<mark_weaver>you're calling 'make-instance' ?

<kurohin>should I not?

<kurohin>alias for make

<mark_weaver>ah, that's an alias for make. okay. never heard of it :)

<mark_weaver>hmm, looks like it should be (define-method (initialize (foo <foo>) initargs) ...)

<mark_weaver>(without the '.' before initargs)

<unknown_lamer>the . before initargs works for me

<unknown_lamer>initargs is the #:rest argument, can't be specialized on

<mark_weaver>well, look at oop/goops.scm

<mark_weaver>look at all the 'initialize' methods defined there

<mark_weaver>kurohin: anyway, I tried unknown_lamer's code, and it seems to work for me. I put a 'display' in there also, and it fires.

<mark_weaver>kurohin: I would first try to see if you can get unknown_lamer's code to work on your system, and then incrementally change it bit by bit into what *doesn't* work for you.

<mark_weaver>hopefully that will shed light on where the problem lies.

<unknown_lamer>kurohin: your code works for me here

<unknown_lamer>after I converted ((next-method)) -> (next-method)

<kurohin>WARNING: (guile-user): `initialize' imported from both (oop goops) and (hell bitmatrix)

<mark_weaver>kurohin: don't export 'initialize' from your module

<mark_weaver>Here's something I wrote on this issue: http://lists.gnu.org/archive/html/guile-devel/2013-03/msg00070.html

<mark_weaver>disclaimer: some longtime CLOS users disagree with me

<kurohin>now it works as it should

<mark_weaver>some CLOS users (notably tupi who hangs out here a lot) wants generic functions to be in a single global namespace.

<unknown_lamer>kurohin: you just want to specialize initialize, no need to re-export it

<kurohin>I thought i might need to be re-exported because it would be called by some more generic variant of initialize, but does define-method acctually add a closure to the allready defined?

<mark_weaver>there's only one 'initialize' generic function. that generic function contains a table of methods. when you do 'define-method', it mutates the table that's within 'initialize'.

<kurohin>ok, that explains it.

<kurohin>thanks again for the help.

<mark_weaver>when you invent your own generic functions, it's important to export them from only a single module. think of that as the interface.

<mark_weaver>other modules can import a generic function from the module that exports it, and can add methods to it. these new methods will then be usable from anywhere that uses that generic function.

<kurohin>the vtable is more visible, and something you directly manipulate (good explination for C++ programmer)

<mark_weaver>however, because GOOPS will *automatically* create a fresh new generic function if it hasn't yet been imported into the module where you define a method, this can cause confusion.

<mark_weaver>if that happens, you'll end up with two different generic functions with the same name, each with their own table of methods.

<mark_weaver>that becomes a mess.

<mark_weaver>now, there are hacks that you can enable that will _merge_ two generic functions together, if you try to import generic functions with the same name into a single module. basically, these create yet another new generic function whose method table contains a superset of those from the imported generic functions.

<mark_weaver>but IMO, that's a mess.

<kurohin>so if I forget a #:use-module in my module definition I could end up with that problem?

<mark_weaver>but we never reached consensus about how best to improve this situation.

<mark_weaver>you'll run into the problem if you define methods of the same name in two different modules, without using imports to ensure that it's the same generic function.

<mark_weaver>and it should be noted that when you specify accessors for a slot, that implicitly defines a method.

<mark_weaver>my position is that the generic function is an interface, and needs to be explicitly defined and exported in a single module and then imported by all of the modules that will add methods to that generic function.

<mark_weaver>see 'define-generic'

<kurohin>ok, sound like a good solution.

<mark_weaver>anyway, if you want to hear an opposing viewpoint, ask tupi about this sometime.

<kurohin>and decide for my self!, are nuts :-) that requires some thinking

<mark_weaver>hehe

<mark_weaver>fwiw, tupi and I agree on this much: there should be just one generic function, not a whole bunch of generic functions with different method tables floating around the system.

<mark_weaver>tupi's position is that generic functions should be in a single global namespace, so that you don't have to worry about explicitly defining and exporting the generic functions.

<mark_weaver>basically, he wants the automatic creation of generic functions in a global namespace, so that there ends up being a single generic function for each name.

<mark_weaver>but what he ends up doing in practice is using the "merge-generics" hack, such that there are a lot of different generic functions of the same name floating around the system, typically about one for each module.

<kurohin>I am still learning scheme (4 days in), so I cant really have a good opinion yet, only that either of those two solutions sound better than how it is now, easy to trip beginners.

<mark_weaver>I'm sure he's not happy about that, but given that he's unable to convince us to make a single global namespace, that's what he's stuck with, given his unwillingness to explicitly define the generic functions.

<mark_weaver>if you're just learning scheme, you might want to try avoiding the object-oriented style at least for a little while, and instead using some other styles like functional programming that are more popular in the scheme world.

<mark_weaver>are you using any teaching materials to help you learn?

<kurohin>something like a (define-interface ...) and make sure (define-method ..) does not accept things before (define-interface ...) that would at least help beginners. as a beginner this looks like a easy mistake to make.

<mark_weaver>yes, definitely

<kurohin>no, not really, if you don't count google and the manual

<mark_weaver>what's your current skill set? what languages do you know? how's your math?

<mark_weaver>(I ask only to help make recommendations for teaching materials)

<kurohin>mostly self learning. C/C++ C# java litle python, emacs lisp, bash, make...

<mark_weaver>The Little Schemer and the Seasoned Schemer are two good books for getting started.

<mark_weaver>There's also the classic Structure and Interpretation of Computer Programs (SICP) that was used for the introductory CS class at MIT for about 30 years. Both the textbook and video lectures are available for free online.

<kurohin>the problem with books is they are to slow to get to intresting parts, I need challange direct from the start. but will check them out, always good to have one at hand for buss-rides.

<alexei>fwiw, in fortran generics can be augmented/merged for the current compilation unit. A generic interface thus augmented may be again made public, of course. Anything else would be impractical with sepearate compilation.

<mark_weaver>well, if you use the same programming style that you'd use in C++, you'll fail to learn the benefits of Scheme, and you won't get much from the experience.

<kurohin>That i understand, but I am heavy user of templates in C++ so recursion is not a problem.

<mark_weaver>I know what C++ has, and I stand by my statement.

<mark_weaver>IMO, you won't appreciate the benefits of Scheme until you've learned some other programming styles that more mainstream languages are unable to accommodate gracefully.

<mark_weaver>If you simply try to translate C++ code into Scheme, it'll just be a waste of time.

<kurohin>and I agree with you. they are very different and requires different ways to thinking. If I wanted C++ i would program i C++(sometimes i want it) but one reason for doing this in scheme is to expose my self for other ways of thinking.

<mark_weaver>If you really want to jump into the deep end of the pool, check out The Reasoned Schemer.

<kurohin>that looks like a book for me. maybe not today, but in time.

<mark_weaver>okay, well, feel free to ask questions here as they arise.

<alexei>I end up with all "objects" being just lists so far with (define get-field1 first) (define get-field2 second)

<mark_weaver>I have to go offline for a while. happy hacking!

<kurohin>will check out the books, thanks again

<nalaginrut>morning guilers~

<madsy>nalaginrut: morning

<nalaginrut>heya

<madsy>Is it possible to make a thread finalizer from the C interface? A function that threads call before being canceled

<civodul>Hello Guilers!

***FractalFive is now known as LAMMJohnson

***LAMMJohnson is now known as FractalFive

<wingo>zomg http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/CharMatcher.java?r=6162f3a87e733aed4308f5110528c2e4da89ed18#1339

<sneek>wingo, you have 1 message.

<sneek>wingo, civodul says: no good reason why procedure-execution-count returns #f AFAICS

<wingo>cool

<wingo>ok, down to one failure

<civodul>oh, funny WHITESPACE_TABLE thing

<civodul>reminds of a discussion about "Unicode support" in JS

<civodul>what a pain

<dsmith-work>Happy Friday, Guilers!!

<wingo>heya dsmith-work :)

<wingo>0 failures, 0 errors!!!!

<wingo>ok as we discussed, i'm merging this thing :)

<wingo>done

<wingo>if you pull from master, make clean, and make, you will have an RTL guile

<davexunit>holy shit

<davexunit>this is truly a magical morning.

<wingo>zow

<dsmith-work>wingo: Whoo@

<wingo>:)

<wingo>whee, removing glil

<wingo>buf, (system xref) needs a rewrite

<wingo>that's the core of guile's geiser support

<davexunit>uh oh.

<civodul>wingo: wo0t!

<mark_weaver>wingo: wo0ho0!

<wingo>:)

*wingo fixing (system xref)

<dsmith-work>What's the minimun verions of auto*tools needed to build from git? I'm not seeing it in README or HACKING. I'm probably just blind today...

<civodul>dsmith-work: should be enforced by configure.ac

<wingo>woo, procedure-callees working again

<mark_weaver>dsmith-work: the main thing is you need automake 1.12 or newer

<mark_weaver>(that's the only one that Debian wheezy users have to deal with, because wheezy comes with automake 1.11.6)

<mark_weaver>the good news is that it's easy to take a newer automake package from a newer version of debian, without pulling in any other dependencies.

<dje42>How hard would it be to let smobs provide their own eq? method? [I know they can currently provide an equal? method.]

<civodul>dje42: impossible

<mark_weaver>dje42: it's important than 'eq?' be a simple pointer comparison.

<mark_weaver>I'd be open to allowing a custom 'eqv?' method, however.

<mark_weaver>s/than/that/

<dje42>Ah. How does the "simple pointer" comparsion come into play for smobs?

<mark_weaver>every smob is heap allocated, so the corresponding SCM value is just a pointer to the smob.

<mark_weaver>in other words, 'eq?' for smobs is always based on identity. if it's the same smob, they are 'eq?', otherwise they are not 'eq?'.

<mark_weaver>if you need something else, you might want to consider _interning_ your smobs, in the same way that symbols are interned. in other words, have some kind of hash table, such that if you create a new smob that's the "same" as an existing smob, the existing smob is returned instead of creating a new one. but this is probably only sensible for immutable objects.

<dje42>What if the smob happens to wrap the same pointer, but the smobs are different? [just trying to dig deeper into where, what, and how things will break]

<davexunit>mark_weaver: I was thinking of doing something like for guile-2d for 2d vectors and rectangles. not sure if it would be worth it.

<dje42>Yeah, I'm thinking of the "interned" approach too. Just trying to explore all the possibilities.

<mark_weaver>then they will not be eq?

<mark_weaver>if you intern, then you might want to use a weak hash table.

<mark_weaver>but I wonder, is it important that 'eq?' work on your smobs?

<mark_weaver>there is a cost associated with maintaining the weak hash table. I'm not sure I'd want to pay that cost unless there was a compelling reason for it.

<dje42>It's not clear yet if eq? will be important. At this point I'm doing research so that if it becomes important, I have a handle on it. One example is smobs that represent symbols in gdb.

<mark_weaver>why not use normal Guile symbols?

<dje42>A few reasons. Perhaps not collectively compelling, but I'm all for incremental complexity. :)

<dje42>In no particular order, gdb symbols are symbols in various programming languages gdb supports. Is there a perfect translation back and forth? I'm not sure.

<civodul>mark_weaver: "symbols" in gdb mean in a different thing (a resolved symbol in a binary, AIUI)

<dje42>Another thing that comes to mind is that gdb already stores the symbol, and there can be a lot of them. Having a copy in Guile as well could be problematic.

<mark_weaver>fwiw, any guile string can be turned into a symbol, and then back again without lossage.

<mark_weaver>okay. I'm not necessarily saying that you should use guile symbols for this. I don't know the relevant issues.

<dsmith-work>mark_weaver: Thanks.

<dje42>Interesting though. I didn't know any string was a valid symbol.

<mark_weaver>but fwiw, I wouldn't consider it a high priority to make 'eq?' work in a sensible way. even in standard Scheme, 'eq?' is only well defined on certain types.

<mark_weaver>dje42: see 'string->symbol' and 'symbol->string'

<dje42>Yeah, I used them a lot in another program. I just never had to worry about the boundaries before.

*wingo forgot entirely about ,inspect

<mark_weaver>'eq?' is really kind of an ugly efficiency hack. the more proper and fundamental equality predicate is 'eqv?', which is an approximation of "operational equivalence".

<dje42>Ah.

<mark_weaver>For all types where '

<mark_weaver>For all types where 'eq?' is defined at all, 'eq?' does the same thing as 'eqv?'.

<mark_weaver>it's just that 'eq?' is faster, because all it has to do is a bitwise comparison of two SCM objects.

<mark_weaver>whereas for some types, 'eqv?' might have to do more. most notable, 'eqv?' checks operational equivalence of two numbers (which is not quite the same as numerical equivalence (=), btw).

<dje42>Righto.

<dje42>Thanks for the info. Off to my day job.

<mark_weaver>For example, 1.0 is numerically equal to 1, but they are not operationally equivalent.

<mark_weaver>okay, ttyl!

<civodul>dje42: Tom Tromey hasn't yet commented on your announcement :-)

<dsmith-work>Wheee!

<dsmith-work>master make check fails with segfault in t-call-cc.scm

<wingo>humm, i have been running ./check-guile

<wingo>i haven't actually run make check ;)

<wingo>that said, make sure you remove your cache/ before compiling

<dsmith-work>Good point.

<wingo>or before running those tests anyway