ChanServ changed the topic of #crystal-lang to: The Crystal programming language | https://crystal-lang.org | Fund Crystal's development: https://crystal-lang.org/sponsors | GH: https://github.com/crystal-lang/crystal | Docs: https://crystal-lang.org/docs | Gitter: https://gitter.im/crystal-lang/crystal
greenbigfrog has quit [Ping timeout: 268 seconds]
jhass[m] has quit [*.net *.split]
repo has quit [*.net *.split]
straight-shoota has quit [*.net *.split]
straight-shoota has joined #crystal-lang
repo has joined #crystal-lang
repo1 has joined #crystal-lang
repo has quit [Ping timeout: 245 seconds]
straight-shoota has quit [*.net *.split]
straight-shoota has joined #crystal-lang
straight-shoota has quit [*.net *.split]
straight-shoota has joined #crystal-lang
repo1 has quit [Ping timeout: 268 seconds]
repo1 has joined #crystal-lang
jhass[m] has joined #crystal-lang
<jhass> !memo greenbigfrog govips looks like another binding to libvips, you still need libvips and depending on your OS something like libvips-dev installed
<DeBot> jhass: Added memo for greenbigfrog.
repo1 is now known as repo
greenbigfrog has joined #crystal-lang
<greenbigfrog> hm, I got disconnected. did jhass happen to reply to my message?
<hightower2> Yes, left you a memo
<hightower2> <jhass> !memo greenbigfrog govips looks like another binding to libvips, you still need libvips and depending on your OS something like libvips-dev installed
<hightower2>
<greenbigfrog> oh, so it's a special thing. I thought it was on all mentions or something. libera is not as cool as I thought /s
<greenbigfrog> Yeah, I think I have all the packages I need. On arch `libvips` should be enough. And on the gobject side, calling the examples etc works
<greenbigfrog> Ok, turns out the `libvips` package actually does not include the typelib file. `libvips-git` from the AUR does. Now I ran into a other issue though
<greenbigfrog> `Error: struct LibVips::Image already defines a field named 'length'`
<oprypin> greenbigfrog, most likely would be that you defined `struct Image` multiple times
<greenbigfrog> Yeah, I didn't though :P The go lib did so if at all ;) I'll try figuring it out
<oprypin> greenbigfrog, can you show some code? but well, if you go through the trouble of reducing the code for the purposes of showing it, then maybe you'll find the issue yourself in the first place
<greenbigfrog> well, that's not gonna work.
<greenbigfrog> still getting used to convos
<greenbigfrog> all code is: require "gobject"
<greenbigfrog> require_gobject "Vips"
oprypin has left #crystal-lang [Bye]
oprypin has joined #crystal-lang
jhass[m] has quit [Ping timeout: 268 seconds]
jhass[m] has joined #crystal-lang
<greenbigfrog> but this is 12 years old code
<greenbigfrog> oh, wait. one is Level the other length. I actually have no idea what I'm doing here as you might be able to tell :)
<greenbigfrog> *Length the other length
<greenbigfrog> I gotta disable that...
<jhass> bin/gi-dump -r Image -n 1 Vips | grep length
<jhass> + length (field, Vips)
<jhass> + length (field, Vips)
<jhass> welp, I guess we now know why the official package drops the typelib, it seems pretty garbage
<greenbigfrog> ah, so the issue is in the typelib
<jhass> I mean maybe it's length vs Length and I'm downcasing something somewhere, idk
<jhass> let's take a look at the gir (XML version of the typelib)
<greenbigfrog> thanks for taking a look :)
<greenbigfrog> btw, filed a feature request after arch forum told me to do so: https://bugs.archlinux.org/task/71058 (I have no idea how any of this really is supposed to work. I have a basic understanding of how it works, but not what should be done by what and where etc)
<jhass> gotta love searching through 40k lines of XML -.-
<greenbigfrog> which file is it?/where do I find it?
<jhass> /usr/share/gir-1.0/Vips-8.0.gir
<greenbigfrog> yeah, I want to bet it's the downcase on Length and length. They're both included in the Vips.gir, and we end up calling downcase on them somewhere in gobject
<greenbigfrog> I tried simply editing the .gir, which didn't work though
<jhass> yeah because it's not actually used by crystal-gobject, the typelib is which is a binary format version of it
<greenbigfrog> ah, right.
<greenbigfrog> Cheers. Now to see if I actually manage to work with this... (:
<jhass> yeah, I figure that'll be the actual challenge :P
<jhass> haha yeah, gi-doc is a hack that's essentially a customized compiler so building it builds crystal itself
<jhass> I guess you're on LLVM 11, get llvm10 :)
<greenbigfrog> oh man... llvm versioning has been paining me...
<greenbigfrog> hm, can't even build it in the crystal:1.0.0 docker image.
<jhass> yeah that one isn't meant to build the compiler iirc
<greenbigfrog> yup. installing llvm-10-dev appears to have got it going though.
<greenbigfrog> btw, is there no output/progress report on purpose?
<jhass> I wouldn't say on purpose, no
<jhass> it's maybe a bit hard to do because especially in release mode we build one giant LLVM module and then most time is just spend in that
<greenbigfrog> yeah
<greenbigfrog> btw, ended up temporarily switching to llvm10. way easier then bothering with docker :)
<jhass> feel ya, I hate docker for local development
<greenbigfrog> oh, btw, is there a way to pregenerate the bindings? (is bindings the right term?)
<jhass> You could crystal src/generator/build_namespace.cr Vips > vips.cr I guess
<jhass> require_gobject is just calling the run macro method with that
<jhass> essentially
<greenbigfrog> I see
<jhass> but note that this in turn contains require_gobject calls to the dependencies
<jhass> so you might want to manually replace/resolve those dependending on what you want
<greenbigfrog> I see
<greenbigfrog> any ideas why I don't have a `resize` function?
<jhass> maybe hacking up src/generator/generator.cr and then running stage3.cr can also work, idk
<greenbigfrog> it's in the gir, but can't find it in the gi-docs, and calling it also doesn't work obviously
<jhass> mmh, where's it supposed to be? I don't see it in https://libvips.github.io/libvips/API/current/VipsImage.html
<jhass> bin/gi-dump Vips | grep resize also turns up empty
<jhass> somehow it has an "introspectable=0" flag in the gir, whatever that means
<jhass> maybe for the vaargs parameter
<jhass> easiest is probably to just reopen lib LibVips and add the definition yourself
<greenbigfrog> I made it this far, but am now kinda stuck https://gist.github.com/greenbigfrog/cd939542a3ade641b8e43455c78d61dc
<greenbigfrog> Ok, so my main issue right now, is that I don't know how to define the C fun to take a Pointer(Vips::Image)
<greenbigfrog> hell yeah
<greenbigfrog> figured it out, I think
<greenbigfrog> I'm proud of myself...
<jhass[m]> congrats :)
<greenbigfrog> how do I pass a string? So, given c function param `const char *name`, what do I have to write in crystal?
<greenbigfrog> ah, `String#to_unsafe`
<greenbigfrog> Hm. I keep running into having to convert between LibVips::Image and Vips::Image. So, the c and go images. Going from C to the Go one is easy since there's a constructor that takes a LibVips::Image*, but not the other way round.
<greenbigfrog> any suggestions on how to handle this?
<jhass[m]> Declare the string as LibC::UInt8* and then you can just pass the string and crystal will call to_unsafe for you
<jhass[m]> The Go one? You mean the Crystal wrapper class? Just passing it should invoke its to_unsafe which returns the pointer
<greenbigfrog> I already had `LibC::Char*`, and just passing the String didn't work. Maybe I'm misremembering.\
<greenbigfrog> yeah, with the "go one" I meant the crystal wrapper class
<greenbigfrog> even if it passes the pointer, it doesn't fix `must be Pointer(LibVips::Img), not Pointer(Vips::Image)`
<jhass[m]> Strange, the declaration and to_unsafe's return value should be `LibVips::Image*`, neither `LibVips::Img*` nor `Vips::Image*` makes sense
<greenbigfrog> Oh, yeah, I was trying around with a `LibVips::Img*` type. Ignore that. Doesn't change anything though. And this isn't the return value, but param. If I use `Vips::Image*` I get the complaint about only primitive types etc being allowed. `must be Pointer(LibVips::Image), not Pointer(Vips::Image)`
<greenbigfrog> starting to wonder if I should just bind vips directly after all
<jhass> greenbigfrog: share what you got?
<greenbigfrog> it's a real mess, but I can try
<jhass> no worries, the entirety of crystal-gobject is a mess :P#
<greenbigfrog> Right now I wrote some code that runs fine in the example, but when called with rest, it nullpointers...
<greenbigfrog> wtf. it just worked
<greenbigfrog> or well, something
<greenbigfrog> why didn't it work earlier...
<jhass> because demo gods :D
<greenbigfrog> it's not even complaining about the `Vips::Image*` not matching `LibVips::Image*`
<greenbigfrog> but why?
<jhass> oh, no more resizing?
<jhass> It never should've :P
<greenbigfrog> or well, why is it complaining in the other one
<jhass> no idea what you've been doing, that's why I wanted to see code :)
<greenbigfrog> well, this was a basic test that I can do anything at all
<greenbigfrog> (i)dhash
<greenbigfrog> I've only found implementations in either intepreted langs (ruby and python), or that use libraries that only allow working with files
<hightower2> :q
<greenbigfrog> hm, weird, even uncommenting my original code makes it work now
<jhass> https://p.jhass.eu/a6.txt works fine for me
<greenbigfrog> smh, you just wrote what I wanted to ask :)
<greenbigfrog> Guess I'll port it over and see if it still works ;)
<greenbigfrog> thanks
<greenbigfrog> ah, I needed `Img**`. makes sense on second thought I guess
<jhass[m]> Yeah, gotta be careful with the stars
<jhass[m]> Honestly the api is not very binding friendly
<greenbigfrog> hm, the vscale param isn't working `fun vips_resize(input : Img*, output : Img**, hscale : LibC::Double, vscale : LibC::Double)`
<greenbigfrog> do I perhaps need to send those optional params differently?
hightower2 has quit [Ping timeout: 268 seconds]
<jhass[m]> Where did you see this documented?
<jhass[m]> Ah, I didn't look carefully. Try my definition and just passing the additional argument. Regular and variadic args are quite different
<greenbigfrog> I think I did, but gonna retry.
<greenbigfrog> Any ideas why this would cause invalid memory access? https://gist.github.com/greenbigfrog/9bfafdac57a1dbc650507011da900732
<greenbigfrog> docs are linked
<greenbigfrog> oh, lol. only now noticed the `...` you had in your version...
<greenbigfrog> but those don't really make a difference anyway since I already have both params. just gonna continue and push the whole thing to github with many TODOs
<greenbigfrog> Hm. It generated `Vips::OperationRelational`, but I can't find where/how to call it. Got an idea jhass?
hightower2 has joined #crystal-lang
<jhass> haha, no. I guess it's for one of the many variadic args APIs
hightower2 has quit [Ping timeout: 264 seconds]
<jhass> can't get vscale to work either, weird
<greenbigfrog> luckily it's not that important for my end use case where I'll be applying this ;)
<greenbigfrog> lol
f1refly has quit [Read error: Connection reset by peer]
f1refly has joined #crystal-lang
<greenbigfrog> Doesn't get very far though because of invalid memory access
<greenbigfrog> I'd really appreciate it if someone could take a look and point me in the right direction
<greenbigfrog> thanks for the help and echo chamber ;)
<jhass> greenbigfrog: https://p.jhass.eu/a7.txt so this works for vscale and I guess is the intended bindings API...
<greenbigfrog> lol, wtf
<greenbigfrog> who came up with this?
<jhass> 🤷
<jhass> btw I don't get why you keep referring to govips :P
<greenbigfrog> wait. hold on
<greenbigfrog> I kept always reading go object. but wait, this has nothing to do with go... 🤦
<greenbigfrog> I'm an idiot, ok
<jhass> haha :D
<greenbigfrog> welp, now I feel like a idiot
<jhass> no worries, I just wondered xD
<greenbigfrog> could've corrected me earlier :)
<jhass> idk, I didn't quite get why you brought it in in the first place :P
<greenbigfrog> yeah, me neither anymore
<greenbigfrog> any idea why the invalid memory access is happenig?
<greenbigfrog> or do I have to rewrite them all like above?
<jhass> anyhow, time for me to grab some sleep. I could actually and unfortunately imagine that your crash might go away if you use the operation API directly, I might give that a shot tomorrow evening if I feel like it and you don't get to it until then. Unfortunately it depends on the GValue API which is still... let's say unpolished. Also I gotta think how to better deal with casting pointers yet
<jhass> again (Vips::Image < Vips::Object < GObject::Object breaks some assumptions in my current approach)
<jhass> I poked a bit at the LLVM IR and we generate C bindings vaargs just as LLVM IR vaargs and I'm not sure that's actually ABI compatbile because LLVM
<greenbigfrog> alright. thanks. have a good night
<jhass> thanks :)
<greenbigfrog> you probably found it yourself by now, but `G_MESSAGES_DEBUG=VIPS` enables a bit more debug printing
deavmi has quit [Ping timeout: 265 seconds]
deavmi has joined #crystal-lang
<greenbigfrog> pushed a bit more to the repo, but also gotta call it now for a bit
hightower2 has joined #crystal-lang
<hightower2> Hey does someone remember where was that forum post from oprypin, summarizing the steps to profile an app?
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #crystal-lang