<Groogy>
but I don't remember what #expressions is supposed to be
<Papierkorb>
what do you want to do?
<Papierkorb>
yield isn't that special in macros, you can work with them. The error shows you it's a Call, so you can do anything to it that a Call can tell you
<Papierkorb>
What may be possible is: 1) make those macros no-op's. 2) having a magic module or class you include, which then does the "parsing" based on the AST
<FromGitter>
<Qwerp-Derp> Why is the tuple `Tuple(Int32, String)` instead of `Tuple(Test, Test)`
<Papierkorb>
Groogy: Not sure if you can grab the AST in there, never tried .. But it should be possible with some gymnastics
<Groogy>
how do you mean make those macro's no ops?
<Groogy>
Well can't you potentially access the constant reference and get the AST nodes from there?
<Papierkorb>
..Define them with an empty body?
<Papierkorb>
Yes @constant references, was what I was playing at. Though maybe not the AST of everything, but you can get the methods and their ASTs
<Groogy>
oooooh
<FromGitter>
<Qwerp-Derp> Any help?
<Groogy>
wait a second
<FromGitter>
<bew> Groogy also I think that with some `method_added` macro-fu there should be a way to avoid having to write the method signature in the macro => your predicates would act on the next defined def
<Papierkorb>
Missing still global functions, but hey
<FromGitter>
<Qwerp-Derp> Any ideas on my tuple thingo?
<Papierkorb>
Groogy: But Clang is so nice and gives me the token stream itself. Which means I have to parse the macros body myself. So that's "great".
<Papierkorb>
Qwerp-Derp, the tuple accepts the union "Test"-type, but it'll happily simplify the definition by itself. you have to `as(Test)` the values if you want to force it.
<Groogy>
@Qwerp-Derp because the compiler can deduce the correct type
<Groogy>
hmmm ClassDef doesn't have any body which is weird
<Groogy>
Def do though
<Papierkorb>
If you want to get into hacky world you can 1) ask @type.methods 2) ask each methods #line_number 3) access __FILE__ and parse it out manually
<Papierkorb>
That may yield the nicest API, but the most complex code
<Groogy>
yeah no
snsei has joined #crystal-lang
<Groogy>
just bit miffed that ClassDef doesn't have a body while Def does
<Papierkorb>
I've never seen a ClassDef in the wild
<Groogy>
yeah TypeNode neither got anything :/
<Papierkorb>
TypeNode#methods
<Groogy>
yeah it go
<Groogy>
got that
<Groogy>
could also define the contract inside the method
<Papierkorb>
Point is, with the "prefix" macro design you don't have to mess with typenode
<Groogy>
with the [] or some other syntax, but then it isn't like "nice native crystal semantics"
<Groogy>
from the Def I should be able to recontruct the exact def of the method
<Papierkorb>
you should be able to simply dump its {{ body }} later on
<Groogy>
hmmm
<Groogy>
so not do a prev_def call kind of thing like I am currently doing?
<Groogy>
though prev_def would let me access the return value easier
<Papierkorb>
prev_def?
<Groogy>
eeeh
<Groogy>
previous_def
<Groogy>
let's you call the previous definition of the method
<Papierkorb>
That's new
<Groogy>
nah it's from Ruby, been there as long as I've been doing Crystal
<Yxhuvud>
I actually don't think that is from ruby.
<Groogy>
pretty sure I've done similar things in Ruby....
<Papierkorb>
In ruby you'd just copy the old method through an alias, and access that
<Groogy>
oooh right true
<Yxhuvud>
Papierkorb: yeah, or make certain it is in the inheritance chain and super your way.
<Papierkorb>
Yxhuvud: Like roda does <3
<Groogy>
either way need to get going, will do this later tonight. contract macros put condition in arrays -> contract macro expands method and defines a wrapper method that calls real implementation surrounded by contracts in the arrays
<FromGitter>
<bew> Is there a way to clear an arrayliteral from macros?
<FromGitter>
<bew> `can only assign to variables, not Path`
<FromGitter>
<bew> seems legit, but as there's no `ArrayLiteral#clear` I can't reset the `STORAGE`
<Papierkorb>
you can reassign
<Papierkorb>
Though you should contain the variable in a macro block if possible to not leak it
<FromGitter>
<bew> what do you mean?
<Papierkorb>
{%begin%}{% foo = [ "bar" ] %} some more code {% p foo %}{% end %}
<FromGitter>
<bew> yes but no I need a constant (a Path) not a variable
<FromGitter>
<bew> Groogy, I think you'll hit this issue as well, here I'm trying to save the contracts in an array, then when I finish using them I try to clear the array
<FromGitter>
<Rinkana> Groogy, what is your opinion for handling Rendering attributes (vertex buffers). Should the renderer keep track of it themselfs for each model or, should they be directly attached to each model and passed along?
<Groogy>
you got it to work with method_added? didn't it just recursevly call it self?
<FromGitter>
<bew> look line 26
<FromGitter>
<bew> I added a way to know which methods have been defined, I don't do it again
<Groogy>
thanks will look at it later today
<FromGitter>
<Rinkana> Ah i see now how you handle it. But you discard the vbo data as soon as it's created and use the GC for the cleanup if needed. Is there a reason not to re-use the buffer and just update them?
<FromGitter>
<bew> about my `method_added` hack to make it work, it's a buggy workaround in fact.. it works in the end, but it'll not define the wanted method only once, as the new generated def will have another representation than the original method, and won't be recognized as the original method (not sure how to explain this..)
<Groogy>
@Rinkana the GC collects it when the object goes out of scope, i.e you are not using it anymore. Update I do all the time for stuff like changing vertices within that object
<Groogy>
to recreate a VBO with new vertex attribs and complete new set of vertex data is going to be as slow as just creating something afresh
<Groogy>
maybe when doing opengl over the x server protocol over network it might give some performance? But it's going to be negible anyway
<FromGitter>
<bew> ===wayland-is-coming===
<FromGitter>
<bew> wow
<Groogy>
It's more likely there is some setting the object is using you forget to reset and you end up with garbage on the screen
<FromGitter>
<bew> (the # make it a title in gitter)
<FromGitter>
<Rinkana> Ah yeah
<FromGitter>
<Rinkana> But can't it happen that the GC is too slow and that too gives you weird stuff on screen?
<Groogy>
no? If the GC is to slow it would just freeze until the GC finishes?
<FromGitter>
<Rinkana> I haven't looked into the GC performance tho
<FromGitter>
<bew> Groogy, do you know if wayland will increase fps (e.g for games) on linux?
<Papierkorb>
The GC is good enough for most workloads. It actually performs remarkably well for being what it is
<Groogy>
What's better is to make sure you don't unnessecairly trigger the GC. Like in the text example, the tmp array of vertices shouldn't be temporary
<Groogy>
@bew no idea
<Groogy>
my gut feeling says yes
<FromGitter>
<Rinkana> Wayland has been comming for quite some time now :P
<Papierkorb>
bew, honestly, the biggest jump in FPS is from better drivers. Wayland could have better FPS, but next to it being more optimized for "modern" graphics, the drivers for it may be better integrated which also helps
<Papierkorb>
Just look at the jump in recent years after Valve ported Steam over
<Groogy>
^
<Papierkorb>
Reminds me that I wanted to check if WINE works now for all games I wanna play. Then I can also get rid of the phat windows gaming VM.
<Papierkorb>
If you disable compositing, yes, which at least KDE/KWin does automatically if a program switches into fullscreen :)
<Papierkorb>
Is there really no way to get my hands on a free and legal Mac OS installation? Even if remote, don't care much. With the latest changes in bindgen and hence Qt5.cr, one could now port it over with some tweaks (if at all) - I hope
<FromGitter>
<bararchy> Dont each class has a `.clone` method ?
<Papierkorb>
Not by default :(
<FromGitter>
<bararchy> how to I clone a class, or maybe I can't ?
<FromGitter>
<bararchy> h
<FromGitter>
<bararchy> oh
<FromGitter>
<bew> there's `.dup` too
<FromGitter>
<bew> one is deep clone, the other is not iirc
<Papierkorb>
#dup is a shallow copy, which may be enough. It doesn't copy values though
<Papierkorb>
#clone is a deep copy
<FromGitter>
<bew> ^
<FromGitter>
<bararchy> values ? as in instance vars for exmaple ?
<Papierkorb>
`foo = [{ 1 => 2 }]; bar = foo.dup` <- foo and bar point to different instances of the array, but the elements are the *same* reference.
<Groogy>
it will copy the instance vars but it won't tell the variables to copy so if they are objects you will get the same reference
<Papierkorb>
So in that `bar << { .. }` would only push something into bar, but `foo[0][3] = 4` would modify "both" hashes, as they're the *same*
<FromGitter>
<bararchy> ok
<FromGitter>
<bararchy> then dup is fine
<FromGitter>
<bararchy> better even
<FromGitter>
<bararchy> :)
<FromGitter>
<bararchy> does it comes automaticlly ?
<Papierkorb>
#dup should be, you can override it if you want too
ShalokShalom_ has joined #crystal-lang
<FromGitter>
<bew> :( I want to bisect the method_added recursion, but I get a compile error when compiling llvm_ext for crystal 0.23.0 :/
<Papierkorb>
I thought llvm5.0 was supported already
<FromGitter>
<bew> maybe it's because I'm trying to compile an old version, so the support is not added yet
<Papierkorb>
That may be an issue
<FromGitter>
<bew> do you know if I can force llvm4.0 for this compilation?
<Papierkorb>
You'd need a llvm4.0 installation for that
<FromGitter>
<bew> hmm I'll downgrade if I can (arch)
<Papierkorb>
I'd try to use the new llvm_ext.cc for the old crystal compiler
<Papierkorb>
... Avoid downgrading if you can
<FromGitter>
<bew> yeah that might be a way better idea, let's try that
<Papierkorb>
A world of pain awaits. If you want that, I'd at least shield my host from messing with that. Maybe with LXC or Docker
<FromGitter>
<bew> I knew that was a bad idea, but didn't thought that much ^^
snsei has joined #crystal-lang
snsei has quit [Ping timeout: 246 seconds]
<Groogy>
@bew why do you have bunch of \ on your macros?
<FromGitter>
<bew> because it's nested macros (in the outer `included` macro)
<Groogy>
ah
<Groogy>
but yeah most seems to be pretty much what I want, only thing missing is invariants and then "tidy" things up by spltiting it into several files nicely
<Groogy>
thanks bew ^^
<FromGitter>
<bew> you're welcome ;) I had a lot of fun doing that ^^
<Groogy>
should be on crystal-clear repo in a few hours
<FromGitter>
<bew> note that it's probably more hacky than what you had before though... (I think)
<Groogy>
It is, but it demonstrates that it is possible
<Groogy>
is what used to generate all of the test code before :P
<Groogy>
also great thing with this, I can make it work for mdoules, structs etc as well
<Groogy>
previous one only worked on class instance methods
<FromGitter>
<bew> oh ok I see, glad it's usable enough then :D
<FromGitter>
<bew> hopefully it'll be even less code when the recursivity of `method_added` will be removed 👍
<FromGitter>
<bew> (and less hack too)
<Groogy>
I am probably gonna add some way for you to declare "don't automatically contract every method, only contract the ones I want" so I am gonna need the ADDED_METHODS anyway
<Groogy>
or something in that style to keep track of which ones to wrap
<FromGitter>
<bew> I think you'll want the other one (CONTRACTS_FOR_DEF)
<FromGitter>
<bew> ADDED_METHODS is roughly all methods
<Groogy>
yeah probably
<FromGitter>
<bew> I've opened #5066 for the recursion issue.
snsei has joined #crystal-lang
snsei has quit [Ping timeout: 246 seconds]
<FromGitter>
<krypton97> has anyone tried crystal with musl instead of libc :) ?