Newest at the top
| 2024-10-19 14:30:30 +0200 | <mreh> | if framebuffers weren't abstracted away... |
| 2024-10-19 14:30:29 +0200 | dcoutts__ | (~duncan@host86-143-111-204.range86-143.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2024-10-19 14:29:37 +0200 | natto | (~natto@129.154.243.159) (Quit: a.) |
| 2024-10-19 14:29:06 +0200 | <mreh> | glReadPixels seems like a way better interface, so I may just add that function to gpipe |
| 2024-10-19 14:28:26 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-19 14:27:45 +0200 | pera | (~pera@user/pera) pera |
| 2024-10-19 14:17:41 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-19 14:14:40 +0200 | <tomsmeding> | (afk) |
| 2024-10-19 14:13:17 +0200 | <tomsmeding> | or just print the values with your prints, that's even easier |
| 2024-10-19 14:13:06 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-19 14:12:45 +0200 | <tomsmeding> | (and as in Control.Exception.evaluate) |
| 2024-10-19 14:12:39 +0200 | <tomsmeding> | mreh: if you do that, make sure to `evaluate (force x)` (as in Control.DeepSeq.force) all previous values to ensure that laziness doesn't make you draw wrong conclusions |
| 2024-10-19 14:12:28 +0200 | <mreh> | one* |
| 2024-10-19 14:12:25 +0200 | <mreh> | yeah, I think it's once for OpenGL people |
| 2024-10-19 14:12:13 +0200 | <mreh> | I might be misremembering |
| 2024-10-19 14:11:58 +0200 | <tomsmeding> | ok I know no opengl so I dunno :) |
| 2024-10-19 14:11:52 +0200 | <mreh> | I'm going to add some prints in there to see exactly where it segfaults |
| 2024-10-19 14:10:02 +0200 | fireking04 | (~user@36-227-66-185.dynamic-ip.hinet.net) (Ping timeout: 255 seconds) |
| 2024-10-19 14:09:36 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-10-19 14:09:24 +0200 | <tomsmeding> | so getting weirdly offset data shouldn't _segfault_, it should just get you incorrect texture data |
| 2024-10-19 14:09:09 +0200 | <mreh> | I think the author is using the wrong function to splice an texture out |
| 2024-10-19 14:09:07 +0200 | <tomsmeding> | I do wonder where the segfault is coming from then; presumably the buffer you get is _data_ and doesn't contain pointers, right? |
| 2024-10-19 14:08:13 +0200 | <tomsmeding> | mreh: I think you're right about at least GL_PACK_ROW_LENGTH, reading OpenGL docs |
| 2024-10-19 14:06:39 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 245 seconds) |
| 2024-10-19 14:06:26 +0200 | <mreh> | I was just calling it and printing the value to force evaluation |
| 2024-10-19 14:05:50 +0200 | <mreh> | tomsmeding: I have no idea, my instrumentation code suggests outside of readTexture2D but if I comment out the call to readTexture2D it works |
| 2024-10-19 14:05:38 +0200 | xff0x | (~xff0x@2405:6580:b080:900:b1c9:c57e:b0f1:f862) |
| 2024-10-19 14:04:47 +0200 | <mreh> | my reading of the gl docs say this should be the image width always |
| 2024-10-19 14:04:46 +0200 | <tomsmeding> | where exactly is the segfault? |
| 2024-10-19 14:04:29 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-19 14:04:11 +0200 | <mreh> | I think the author is misusing `glPixelStorei GL_PACK_ROW_LENGTH` |
| 2024-10-19 14:03:23 +0200 | <mreh> | tomsmeding: correct! it's weird |
| 2024-10-19 14:03:11 +0200 | <tomsmeding> | mreh: so you're saying, if you call readTexture2D with w/h arguments that cover the full texture, all is fine; but if you read only part, then it segfaults? |
| 2024-10-19 14:02:59 +0200 | <mreh> | I think it's one for someone who understands gl better |
| 2024-10-19 14:02:02 +0200 | <mreh> | it's all single threaded |
| 2024-10-19 14:01:43 +0200 | <tomsmeding> | which might be very confusing |
| 2024-10-19 14:01:34 +0200 | <tomsmeding> | did you check that this thing is only called from one thread so that your prints don't get interleaved with prints from other threads? |
| 2024-10-19 14:01:08 +0200 | <tomsmeding> | ah yes |
| 2024-10-19 14:01:04 +0200 | <tomsmeding> | (oops) |
| 2024-10-19 14:00:58 +0200 | <tomsmeding> | .urlse |
| 2024-10-19 14:00:51 +0200 | <tomsmeding> | partially :p This dance quite a bit more intricate than what one would do in e.g. C, but then, you do get a nice language in return |
| 2024-10-19 14:00:24 +0200 | <mreh> | all this wouldn't be an issue if I could find out why this segfaults unless I read the entire texture https://hackage.haskell.org/package/GPipe-Core-0.2.3.1/docs/src/Graphics.GPipe.Internal.Texture.ht… |
| 2024-10-19 13:59:59 +0200 | <mreh> | I hope you're not being sarcastic! |
| 2024-10-19 13:59:33 +0200 | <tomsmeding> | are you liking haskell so far? :p |
| 2024-10-19 13:59:06 +0200 | <tomsmeding> | as for how you get a FinalizerPtr: look at the docs for FunPtr |
| 2024-10-19 13:59:05 +0200 | <mreh> | thanks |
| 2024-10-19 13:58:46 +0200 | troydm | (~troydm@user/troydm) troydm |
| 2024-10-19 13:58:40 +0200 | <tomsmeding> | if you can't mallocForeignPtrArray you'll have to newForeignPtr with a FinalizerPtr corresponding to free() |
| 2024-10-19 13:58:03 +0200 | <tomsmeding> | then use Data.Vector.Storable.unsafeFromForeignPtr0 to create your vector, which passes ownership of the ForeignPtr to the vector |
| 2024-10-19 13:57:36 +0200 | <tomsmeding> | and copy your texture data to it |