Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 07 18:12
    HertzDevil labeled #13052
  • Feb 07 18:12
    HertzDevil labeled #13052
  • Feb 07 18:12
    HertzDevil labeled #13052
  • Feb 07 18:12
    HertzDevil opened #13052
  • Feb 07 17:49
    straight-shoota closed #13051
  • Feb 07 17:46
    beta-ziliani milestoned #13051
  • Feb 07 17:46
    beta-ziliani milestoned #13051
  • Feb 07 14:03
    beta-ziliani review_requested #13050
  • Feb 07 13:59
    straight-shoota labeled #13051
  • Feb 07 13:59
    straight-shoota assigned #13051
  • Feb 07 13:59
    straight-shoota opened #13051
  • Feb 07 13:50
    straight-shoota milestoned #13050
  • Feb 07 13:50
    straight-shoota milestoned #13050
  • Feb 07 13:47
    Blacksmoke16 labeled #13050
  • Feb 07 13:47
    Blacksmoke16 labeled #13050
  • Feb 07 13:47
    Blacksmoke16 labeled #13050
  • Feb 07 13:47
    Blacksmoke16 labeled #13050
  • Feb 07 13:39
    bcardiff opened #13050
  • Feb 07 10:33
    straight-shoota closed #12965
  • Feb 07 10:33
    straight-shoota closed #12966
George Dietrich
@Blacksmoke16
abstract struct Callable
end

struct Proc1 < Callable
  def call # define args/return type
  end
end

struct Proc2 < Callable
  def call # define args/return type
  end
end

hash = Hash(String, Callable).new
the gist of it is that you cant have a hash with type of Proc, would need to specify the types of procs that can be in the hash
i suppose technically the macro approach you wanted to take would work around this by defining a hash literal, which would essentially type itself
From IRC (bridge bot)
@FromIRC
<Guest64> hmm, wrapping the procs inside a struct might work. i never thought of that
<Guest64> could you expand more on this hash literal you speak of?
George Dietrich
@Blacksmoke16
the type of literal hashes are inferred based on the values in the literal
but hashes with a lot of unioned types is kinda meh
From IRC (bridge bot)
@FromIRC
<Guest64> yea thats probably going to be messy since these procs vary in arguments from 0 to 6 with various types ranging from simply ints up to pointers to structs
<Guest64> although thats neat that works like that. ill keep that in mind
From IRC (bridge bot)
@FromIRC
<Guest64> @Blacksmoke16: I am having a bit of trouble implementing a simple test for your callable suggest: https://play.crystal-lang.org/#/r/biyo im probably not doing this right at all heh
George Dietrich
@Blacksmoke16
prob not going to be that easy when you add more, as the compiler wont be able to guarantee that the value returned from the hash has that method with those arguments
From IRC (bridge bot)
@FromIRC
<Guest64> hmm yes, i will have to ponder about that. thanks for the assistance
George Dietrich
@Blacksmoke16
are the string keys anything significant?
Kirk Haines
@wyhaines
Yeah, it won't work once you add a second struct.
From IRC (bridge bot)
@FromIRC
<Guest64> the string keys are just a way to fetch the correct proc pointer from the hash to return to the dynamic linker. the dynamic linker actually gives me a char*, but i convert it to a string for use.
Kirk Haines
@wyhaines
I've been down this road when I built my #send implementation. :)
From IRC (bridge bot)
@FromIRC
<Guest64> if it matters im attempting to implement rtld-audit for fun and experience: https://man7.org/linux/man-pages/man7/rtld-audit.7.html
George Dietrich
@Blacksmoke16
From IRC (bridge bot)
@FromIRC
<Guest64> i have everything working, im just testing new theories and ways to generate code
George Dietrich
@Blacksmoke16
if the strings are just a way to know what the proc is, you can make the proc's class the key of the hash
could also ofc have a #get method that returns the related Callable instance that you could then directly invoke #call on
but i just combined them into 1 method
Kirk Haines
@wyhaines
Yeah. You can't get away from storing the class/type of Proc or Struct somewhere, in some form.
From IRC (bridge bot)
@FromIRC
<Guest64> random question: is there a way for crystal to expand macros in other files, then move the expanded code into another file for use? if that makes any sense.
From IRC (bridge bot)
@FromIRC
<Guest64> i wish there was better docs for macros somewhere. it seems to have all these cool features but i cant make heads or tails of them
George Dietrich
@Blacksmoke16
you already asked this and we answered it twice :P
From IRC (bridge bot)
@FromIRC
<Guest64> ha, i suppose i did, my bad
George Dietrich
@Blacksmoke16
i will say that mutable constant approach is kinda a smell
im still of the opinion you dont even need a macro
From IRC (bridge bot)
@FromIRC
<Guest64> i guess the problem i am trying to solve is that i have all these function prototypes that vary radically, but the internal body consists mostly of the same method calls plus a bit of dynamic logic based on the function being called, hence the yeild in the macro. i think in the end i was just exploring different options so that i did not have to
<Guest64> write boilerplate 50+ times
Kirk Haines
@wyhaines

A macro generates code only in the location in which it is executed.

However.....you can make what you want to do work with macros.

Macros have access to constants.

So, if you generate all of your procs, assigned to a constant name, under a common namespace, then in your main.cr you can iterate over
that namespace (see Crystal::Maros::TypeNode in the Crystal API docs), find the names of all of your Proc constants, and build your master hash.

George Dietrich
@Blacksmoke16
i.e. in the previous example the logic that was like arg0 + arg1 is the stuff thats unique per proc? but there is also common logic between them all?
From IRC (bridge bot)
@FromIRC
<Guest64> yes corrent, a fair bit of common logic
<Guest64> im reading https://crystal-lang.org/api/1.0.0/Crystal/Macros/TypeNode.html atm like wyhaines suggested
Kirk Haines
@wyhaines
TypeNode just shows you what you have access to within a TypeNode. i.e. #constants, so you can iterate constants.
George Dietrich
@Blacksmoke16
Kirk Haines
@wyhaines
The fact that macros have access to constants means that you can use them to store and gather information from a wide variety of locations, and use it in a central location.
George Dietrich
@Blacksmoke16
auto registers proc types in the collection type, and shows how you can do before/after logic
can remove the #register method then too
From IRC (bridge bot)
@FromIRC
<Guest64> wait i am a bit confised here. you can use {% %} and {{ }} outside of a macro def block?
George Dietrich
@Blacksmoke16
yes, this is also macro code
macro some_name are reusable portions of macro code, but you can also use the macro code outside of them
the end result is the same. Code generated by the macro code is included where it's called as if you manually typed it
From IRC (bridge bot)
@FromIRC
<Guest64> okay, that is pretty cool now, im starting to understand this system a bit more
<Guest64> thanks for the aid