<FromGitter>
<fridgerator> @codingphasedotcom have you started doing any crystal casts yet?
<FromGitter>
<elorest> Railsconf has been pretty good so far. Haven’t heard a single elixir talk.
<FromGitter>
<elorest> @codingphasedotcom do you have any examples projects with rocky I could play with?
<FromGitter>
<fridgerator> " Haven’t heard a single elixir talk" that's surprising
<FromGitter>
<codingphasedotcom> @fridgerator i have youtube channel. Youtube.com/codingphase
<FromGitter>
<codingphasedotcom> I started making the tutorials there
<FromGitter>
<fridgerator> awesome
<FromGitter>
<codingphasedotcom> Building the crystalcasts.io site with crystal right now as we speak. I started with laravel but it wouldnt be right if it wasnt built on crystal
<FromGitter>
<fridgerator> lol
<FromGitter>
<elorest> @codingphasedotcom Yeah specifically it wouldn’t be write if it was built in laravel. lol
<FromGitter>
<codingphasedotcom> Lol
<FromGitter>
<elorest> @fridgerator Yeah I’m happy about that though. I mean having it in phoenix was already a bit to close for comfort.
<FromGitter>
<fridgerator> lolol
<FromGitter>
<elorest> DHH’s speach this morning was pretty mellow. He really seemed more than ever like the high priest of rails though.
<FromGitter>
<codingphasedotcom> I have a large following on youtube and everyone following me on this journey of crystal lang lol i feel we like the pilgrims right now
<FromGitter>
<elorest> yeah it’s the wild west.
<FromGitter>
<codingphasedotcom> It might sound crazy but this morning i had a dream that airbnb switched to crystal lang
<FromGitter>
<codingphasedotcom> Lol
<FromGitter>
<codingphasedotcom> All we need is one large company to give it a cosign
cerulean has quit [Quit: leaving]
marcosdsanchez has joined #crystal-lang
marcosdsanchez has quit [Client Quit]
<FromGitter>
<sdogruyol> :+1:
Kug3lis has joined #crystal-lang
Kug3lis has quit [Remote host closed the connection]
Kug3lis has joined #crystal-lang
Kug3lis has quit [Remote host closed the connection]
Kug3lis has joined #crystal-lang
Kug3lis has quit [Ping timeout: 255 seconds]
yogg-saron has joined #crystal-lang
<olbat>
Hello, I'm writing a wrapper to a lib and I want to do something like this: https://carc.in/#/r/1xks . Is there a better way to do it ? If not, how can I convert an enum value from a C binding to a Crystal one ?
Qchmqs has joined #crystal-lang
<olbat>
I've tried to specify a type for both of the enums and to use something like .to_i32.as() but I cant make it work
<olbat>
(is it just stupid to try to wrap the enum ? :])
<FromGitter>
<bew> I love the `These modules were not reused:` section when compiling crystal master, it's huuuge
<FromGitter>
<bew> simply 17 page (918 lines!!) of terminal printing^^
<FromGitter>
<bew> :( I have 5.8G available, and `make spec` keeps crashing with `fork: Cannot allocate memory` .....
bjz has joined #crystal-lang
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
<olbat>
oops I forgot about aliases, thank you @bew !
<FromGitter>
<bew> yw :)
<FromGitter>
<greentornado> anyone has an example of query pgsql jsonb using crystal-pg please :D
<FromGitter>
<KCreate> Hey, are there any design docs on how threading support is going to work? Will it be a cooperative effor just like fibers or will threads be truly independent?
unshadow has quit [Ping timeout: 260 seconds]
unshadow has joined #crystal-lang
<FromGitter>
<bew> @KCreate I don't remember where I've read that, iirc threading support will allow to run fibers in separate threads, you won't need to specify anything, and existing programs could have some fibers running in separate threads without modification.. (just recompilation)
<FromGitter>
<bew> In some places you'll be able to explicit the need of a thread for a specific fiber (eg. for high cpu intensive computations)
<FromGitter>
<KCreate> so no `Fiber.yield` anymore? :P
<FromGitter>
<bew> In some places, yes ;)
<FromGitter>
<bew> I think
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<chuckremes> @KCreate I’m interested in learning more about this too. I’m hoping Crystal doesn’t share a limitation with Ruby wherein fibers cannot migrate between threads. That is, if you create a fiber in one thread you cannot yield it and then resume it from another thread.
Dreamer3 has joined #crystal-lang
<FromGitter>
<ysbaddaden> no, any thread should be capable to resume any fiber
<FromGitter>
<bew> ooh don't know how, but would be awesome
<FromGitter>
<bew> will*
<FromGitter>
<ysbaddaden> concurrency is at the fiber level; threads are just a mean to achieve parallelism, they don't hold/memorize anything but `Fiber.current` (the one it runs)
<FromGitter>
<ysbaddaden> the complexity isn't to share fibers across threads, but have fast-but-safe context-switches when pulling a fiber to resume
<FromGitter>
<bew> and sharing all datas from fibers to fibers on multiple threads, no?
<FromGitter>
<bew> (via thread sagfe channels or sth?)
<FromGitter>
<ysbaddaden> I believe this is the developer responsibility
<FromGitter>
<ysbaddaden> aka. don't share data without locks
<FromGitter>
<ysbaddaden> yes, communication structs like Channel must be concurrency-safe
<FromGitter>
<bew> yah but if I understand well, th developper may not need to specify (or know) which fibers will be on a separate thread or not, so how can he know which communication to use?
<FromGitter>
<bew> s/if I understand well/iirc
<FromGitter>
<ysbaddaden> well, you have 2 fibers : you need a Channel or an equivalent struct to communicate safely
<FromGitter>
<ysbaddaden> once you spawn you better not rely on any mutable variable, unless you pass it though a Channel; that's already true
<FromGitter>
<chuckremes> +1
<FromGitter>
<KCreate> will the api be different for fibers and threads? so something like `spawn` and `spawn_thread`?
<FromGitter>
<ysbaddaden> it could be nice to introduce a `DualChannel` or `Channel.pair` for bidirectional communication, btw
<FromGitter>
<ysbaddaden> I have no idea, but I don't remember having control over threads
<FromGitter>
<ysbaddaden> that is `spawn` and nothing else
<FromGitter>
<ysbaddaden> just like go only provides `go` AFAIK
<FromGitter>
<KCreate> so Fibers (as we have them now) will become obsolete?
<FromGitter>
<ysbaddaden> no
<FromGitter>
<ysbaddaden> they're the same, they would just be shared by a pool of thread
<FromGitter>
<bew> they'll be just Super-F
<FromGitter>
<KCreate> Ah i see
<FromGitter>
<KCreate> so one would spawn multiple fibers, and a pool of threads would then each pick up a fiber and work on it?
<FromGitter>
<sdogruyol> Fiber 9000+
<FromGitter>
<chuckremes> @ysbaddaden Are you working on this?
<FromGitter>
<ysbaddaden> nope, just followed intent
<FromGitter>
<chuckremes> Ok. Did you learn this from conversations in irc/gitter, mailing list, in person meetings, …?
<FromGitter>
<luislavena> @chuckremes you can get most of these details by looking at the code and changes in the thread-support branch
<FromGitter>
<bew> and how do you follow changes on this branch? is there away to get notifications or sth?
<FromGitter>
<KCreate> just take a look at the commit history every now and then
<FromGitter>
<bew> hmm
<FromGitter>
<chuckremes> @luislavena I’ve heard conflicting reports about which branch to look at. There is the thread-support branch and also the single-msqueue branch.
<FromGitter>
<KCreate> that's what i do mostly (altough i'm not always sure what they're working on :smile:)
<FromGitter>
<luislavena> guess single-msqueue is the updated version of thread-support
<FromGitter>
<KCreate> what does msqueue stand for?
<FromGitter>
<mverzilli> hi! what Julien and Luis said is correct, and there are also some experiments going on on single-msqueue, as Chuck mentioned. we also keep in mind the request Chris (RX14) made on the list to somehow better communicate the roadmap as regards parallelism. the person who's currently in charge of collecting and communicating status is on vacations (spalladino), that is in part why status updates have been a bit slow
<FromGitter>
<fridgerator> @KCreate microsoft queue, lololololol
<FromGitter>
<bew> thanks @mverzilli for precisions
<FromGitter>
<mverzilli> also, it's a bit difficult to come up with a "classic" roadmap where you just produce a list of bullet points for this, there's a lot of experimentation and going back and forth
<FromGitter>
<KCreate> @fridgerator microsoft smart queue center
<RX14>
I feel crystal development in general has been a bit slow recently, is it because of the codecamp preparations?
<FromGitter>
<mverzilli> no, it's not. one issue that concerns us as of late is the growing compilation times and memory consumption
<FromGitter>
<chuckremes> @mverzilli Thank you for those details. I understand a roadmap is difficult but it would be useful to know the goals you are trying to accomplish. I’ll take a look at these branches to understand the current direction better.
<FromGitter>
<mverzilli> so we're doing some experimentation with other approaches to type inference
<RX14>
I really think compilation times and memory consumption isn't a really big issue
<FromGitter>
<chuckremes> @luislavena Thanks for the link. I didn’t know I could do those branch comparisons on GitHub!
<RX14>
I can compile the entire spec suite in about a minute with 5gb ram
<RX14>
it's really not that bad
<RX14>
I needed more than 16gb of ram to just link llvm with debug info
<RX14>
it locked up my whole pc because i had no swap
<FromGitter>
<mverzilli> when you make a change to the compiler it takes many seconds to compile and run the tests, the development loop isn't very enjoyable, and we don't want to find out down the road that you can't build something bigger than the compiler because the compiler doesn't scale
<RX14>
but I feel we're putting the cart before the horse
<RX14>
there's a reason that there's no project bigger than the compiler, and it's the feedback we get all the time
<FromGitter>
<bew> @mverzilli can I find unofficial (even little) documentations or things about current experimentations? (without diving into the code, which'll be another step)
<RX14>
crystal is immature for small projects
<RX14>
you can't have everything but I feel that features and polish are the most important
<RX14>
windows support, parallelism are what people appear to be waiting on for crystal, not a incremental compiler
<FromGitter>
<mverzilli> @RX14 problem is, we don't want to realize further down the road that we need to impact the language specification in order for Crystal to work in big projects. if we add a native zip inflater written in Crystal, maybe even a simple "Hello world" will take seconds to compile. that's why we don't want delay that issue.
<RX14>
but my point is that if we waste all year working on this we'll miss the boat and crystal will die completely
<RX14>
sorry, we may miss the boat
<RX14>
that was meant to be hypothetical
<FromGitter>
<mverzilli> yeah, I understood :). I don't think we're going to waste all year
<vegai>
hmm, do people actually need parallelism
<RX14>
as someone who doesn't often work on the compiler I feel that it's a bit of wasted time
<vegai>
I mean, some do obviously
<FromGitter>
<mverzilli> the single-msqueue branch works pretty well on Linux and it sucks on OSX
<RX14>
or at the very least the effort needs to be split
<RX14>
there needs to at least appear to be progress on visible parts
<RX14>
and as someone who doesn't work at manas, it doesn't appear to be the case on the surface
<RX14>
I know there's work going on but it's almost as important to keep the community excited about the future
<RX14>
and I feel that that's what needs to improve lately
<FromGitter>
<chuckremes> I find myself nodding in partial agreement with @RX14
<FromGitter>
<chuckremes> Communication to and with the community is important. We want to be excited about what’s coming next and to hear about it.
<FromGitter>
<mverzilli> yeah, I understand that point of view. let me try to discuss these things with the team and see how we can get better at that :).
<FromGitter>
<mverzilli> (I hate that smiley in Gitter :P)
<RX14>
I don't want to sound totally negative
<RX14>
because that's not the case
<RX14>
but these are just things i've noticed recently
<FromGitter>
<mverzilli> no, not at all Chris!
<RX14>
also, I read somewhere that one problem with a self-hosting compiler is that your language eventually gets optimized for writing compilers, maybe that kind of sums up my problems with the current roadmap
<FromGitter>
<KCreate> This reminds me of Ken Thompson hiding malicious code in the compiler itself
<RX14>
@mverzilli I honestly don't know what proportion of the time the team spends writing crystal code outside the compiler, it depends how much crystal is used internally I guess
<FromGitter>
<KCreate> Off-Topic: Where did you guys learn about compiler writing? Did it start with crystal itself or did you have experience before-hand?
<FromGitter>
<mverzilli> @RX14 it really doesn't. every month we try to gather and decide what is the most reasonable thing to tackle next, from the point of view of Crystal's own growth. it isn't influenced by how we're using Crystal internally
<FromGitter>
<mverzilli> @KCreate that's a better question for Ary :). What I know is he wrote "Descent" an Eclipse based D IDE like 12 years ago, and there he learn a lot of tricks that are related
<FromGitter>
<mverzilli> apart from that, a lot of experimentation, and a lot of projects written in different programming languages which give you an idea of the kinds of things you want and the ones you sort of can live without
<RX14>
I do love the way crystal takes my favourite ideas from so many programming languages
<FromGitter>
<KCreate> Yea crystal feels like a frankenstein of only the good parts
<RX14>
frankenstein? i'd put it a bit more favourably than that :)
<FromGitter>
<mverzilli> lol
<FromGitter>
<KCreate> Yea probably should've come up with a more suitable term lol
<FromGitter>
<fridgerator> ever read frankenstein? frankenstein (the monster) was a badass
<FromGitter>
<mverzilli> (btw, I think single-msqueue is actually a typo, it should be single-msgqueue :P)
<FromGitter>
<fridgerator> but yeah, in pop culture frankenstein has a negative connotation
<RX14>
I'll edit my stackoverflow answer to include a link to your repo
<FromGitter>
<ysbaddaden> hopefully, because I'm not trying to compile LLVM for ARM ever again
<RX14>
haha
<RX14>
llvm took so much memory to link for me... i imagine you couldn't generate a debug build at all
<vegai>
Arch Linux ARM works really well on Raspberry
<RX14>
or at least you'd be swapping the whole time
<vegai>
and includes almost all the software that the Real Arch does
<FromGitter>
<ysbaddaden> to build the package I cross compiled, then linked in raspbian qemu with llvm 3.9 from unstable and a few other packages, then fpm built the package
<FromGitter>
<ysbaddaden> the binary may run on other distributions, it depends on glibc, libtinfo and libedit, only
<RX14>
i'd like to automate the entire release process
<RX14>
releasing should be editing the changelog, pushing a tag and waiting
<RX14>
and automating packaging for a whole lot of platforms
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<FromGitter>
<ysbaddaden> yeah, that would be great
<FromGitter>
<ysbaddaden> though distributions should eventually take the burden
<RX14>
yup
Yxhuvud has quit [Remote host closed the connection]
Yxhuvud has joined #crystal-lang
<FromGitter>
<KCreate> Can't test it right now, but is it possible to do something like `crystal shards install <my-shard-name>`?
<FromGitter>
<KCreate> which would automatically ad it to shards.yml
<FromGitter>
<KCreate> btw, I'm making steady progress with my virtual machine written in Crystal ⏎ https://github.com/KCreate/stackvm ⏎ It's still really inefficient and the code is a huge mess but the instruction set is now fully implemented.
<FromGitter>
<bew> awesome work already!
<RX14>
I just restarted the jenkins master by accident while it was building
<RX14>
and it seems to have picked up right where it started
<RX14>
where it left off*
<RX14>
i guess since the slave processes don't die it's fine
<RX14>
which is reassuring
aladagemre has joined #crystal-lang
<FromGitter>
<bew> How did you designed your vm @KCreate ? Did you design everything from scratch?
<FromGitter>
<KCreate> I took inspiration from pretty much any resources I could find. x86, avr assembly, mips all helped a ton!
<FromGitter>
<KCreate> Also some feedback from some really smart guys in the ##asm irc channel on freenode
<FromGitter>
<KCreate> It's also the second time I'm designing a toy vm from scratch
<FromGitter>
<bew> wow, that's really cool (you must have alot of time for all this, na?)
<FromGitter>
<KCreate> haha, yea I do
<FromGitter>
<KCreate> well right now I'm on "holidays" so I've got more time than usual
<FromGitter>
<bew> side-question: how many project are u doing concurrently?
unshadow has joined #crystal-lang
Qchmqs is now known as webindz
<RX14>
oh i see why my jenkins jobs are failing now!
webindz is now known as indzign
indzign is now known as qchmqs
qchmqs has quit [Quit: Konversation terminated!]
qchmqs has joined #crystal-lang
<RX14>
damn race conditions :)
unshadow has quit [Quit: leaving]
<FromGitter>
<bew> what is the jenkins for? ci?
<zipR4ND1>
hey all, when creating an object with object.allocate is there a way to assess if it is valid later, making sure all of its non-null attributes have been set ?
<RX14>
no
<RX14>
why are you using allocate?
<FromGitter>
<bew> I don't think so, the compiler checks that all you `initialize`s init all instance variables at compile-time, but at runtime you can't
<zipR4ND1>
because I like this syntax so much: Object.define { name = "my name" }
<RX14>
what?
<zipR4ND1>
def self.define; inst = allocate; with inst yield; inst; end
<RX14>
why not just .new
<RX14>
instead of allocate
<zipR4ND1>
because new asks for all the non null values to be already set ..
<RX14>
good
<zipR4ND1>
yeah true
<RX14>
why not just make your constructors nicer?
<Papierkorb>
zipR4ND1: that is a security feature by Crystal, and you're removing it without need. you shouldn't.
<zipR4ND1>
yeah I know, your right
McSoFake has joined #crystal-lang
yogg-saron has quit [Remote host closed the connection]
qchmqs has quit [Ping timeout: 240 seconds]
mark_66 has quit [Quit: Leaving.]
unshadow has joined #crystal-lang
<RX14>
has anyone got some code which would fail on 32bit linux but work no 64bit linux? or the other way around?
<RX14>
I don't trust `linux32`
<RX14>
it doesn't seem to be working on jenkin sat least
<BlaXpirit>
RX14, u want crystal code?
<RX14>
yes
<BlaXpirit>
LibC::Long is supposed to be different size but carcin says it's the same. wasn't carcin 32bit?
<zipR4ND>
wow, just found out about the meaning of \{% %} nested macros. 5 minutes ago I thought this https://play.crystal-lang.org/#/r/1xpz was just not possible in crystal
<FromGitter>
<fridgerator> :thumbsup:
<zipR4ND>
this is nowhere documented. I mean the fact that we can have shared variables between macro calls ..
<FromGitter>
<bew> yeah I discovered the sharing stuff by mistake a while ago, I was *woaaaaaaa*
<FromGitter>
<bew> nice use of nested macros though x)
<FromGitter>
<bew> (note: `{length: ItegerType}` is not used in your macro)
<zipR4ND>
oh yeah
<zipR4ND>
this will need to be checked against the provided arguments
<zipR4ND>
still trying to figure out a nice api for the graphql implementation
<zipR4ND>
I mean having the ObjectType as a mixin might be really nice because it lets you extend your existing models
<zipR4ND>
(in your monolithic crystal mega app that your company has been developing for decades :D)
unshadow has quit [Ping timeout: 260 seconds]
<RX14>
sometimes I feel like creating my own CI server just for crystal
<RX14>
jenkins is just a bit ill-suited
<FromGitter>
<bew> are you building it in crystal? *I'm out*
<RX14>
yeah I would build it in crystal :P
zipR4ND has quit [Ping timeout: 260 seconds]
<FromGitter>
<bew> is there a way to catch Out of emory error ? (malloc fail)
<FromGitter>
<bew> memory*
<FromGitter>
<Sija> not without creating a wrapper around the bin
<FromGitter>
<Sija> u could override `__crystal_sigfault_handler` but that’s hackish at least
<FromGitter>
<bew> is it possible to make a `Pointer#malloc?` ?
<RX14>
there's Pointer.malloc
<FromGitter>
<bew> yeah but it does not return nil when `out of memory`
<RX14>
@bew what does it return?
<FromGitter>
<bew> a pointer.... which could be null I think, my bad
<FromGitter>
<bew> well no, `while (mem = Pointer(UInt8).malloc(Megabyte)) && !mem.null?` never return `false` :(
<Papierkorb>
the garbage collector should eat unreferenced blocks in the meantime
<FromGitter>
<bew> I push `mem` in a `Array(Pointer(UInt8))` to prevent that
<FromGitter>
<bew> I get the message from GC: `GC Warning: Out of Memory! Heap size: 5997 MiB. Returning NULL!` but it seems I never get null.. (will recheck..)
<FromGitter>
<bew> I'm trying to eat all the memory (first I only wanted to get the available ram the hard way), but now I just want to understand why I don't get NULL!!
<Papierkorb>
No POV needed, that's legal syntax BlaXpirit
<Papierkorb>
bew, yep.
<FromGitter>
<Sija> ouch, looks cryptic
<FromGitter>
<bew> nice shorting
<Papierkorb>
Useful in (auto-)generated code
<BlaXpirit>
Papierkorb, yeah but in one of the contexts it's always meaningless, "undefined method '*' for Void:Class" which is fun
McSoFake has quit [Quit: leaving]
<FromGitter>
<bew> What's the difference memory-wise btw calling `GC.malloc` & `Pointer(Void).malloc` ? (my program does work with the first one, crash with the second)
<FromGitter>
<bew> is it a bug ? (looks like one...)
<BlaXpirit>
bew, it is not a bug. fixing this bug, if it is considered such, would drastically slow down Crystal
<BlaXpirit>
Pointer.malloc is not only doing what I described it as, it also sets all bytes in the memory region to zeroes
<BlaXpirit>
if you have a memory region starting at 0 and try to set its bytes, then yeah, segfault
<Papierkorb>
why would it slow down Crystal? a nullptr check has to be done.
<BlaXpirit>
i would prefer it not being there, especially in release mode
<BlaXpirit>
what do you do if the pointer is null? uhhhhh crash anyway
<Papierkorb>
considering that all structures built upon that function internally it means that not checking for a nullptr means that in the scenario of OOM all programs would just crash with a nasty segfault
<BlaXpirit>
got any better ways out of an OOM? there's no generic way out of it
<Papierkorb>
A proper "OOM, I'm outta here" would already be a huge improvement
<Papierkorb>
you see a nullptr segfault, which can mean literally anything
<BlaXpirit>
i don't think crashing with a different error message would be worth the slow down
<Papierkorb>
what slow down?
<Papierkorb>
There is none
<BlaXpirit>
except you see "GC Warning: Out of Memory! Heap size: 6015 MiB. Returning NULL!"
<BlaXpirit>
and then segfault
<BlaXpirit>
pretty clear
<Papierkorb>
That's dirty as heck
<Papierkorb>
If crystal wants to be a memory safe language, it must do proper checks itself
<Papierkorb>
last time I looked crystal sold that as feature
<BlaXpirit>
this GC is dirty as heck anyway, needs a rework
<Papierkorb>
The GC has nothing to do with having a proper nullptr check
<BlaXpirit>
Papierkorb, the thing is the check is being done twice because GC has to acknowledge it returns a null ptr
<Papierkorb>
what expensive check?
<BlaXpirit>
i would feel better if it wasn't done twice
<Papierkorb>
you mean that `if ptr`?
<Papierkorb>
Really?
<BlaXpirit>
i didnt say expensive this time at least
<Papierkorb>
that was your main point, it being expensive
<BlaXpirit>
it's expensive when multiplied by the number of allocations, yes
<Papierkorb>
huh
<Papierkorb>
Profile it.
<Papierkorb>
I very much doubt it to be of any impact at all
<RX14>
GC_Malloc already does a heck of a lot
<Papierkorb>
Not doing security is a bad idea in general
<BlaXpirit>
while we're at it, if it was me, i wouldn't zero all memory before overwriting it all anyway with mandatory initializers
<FromGitter>
<jwoertink> Can someone help me understand how `ECR.embed` works? I can pass a string literal and io object and it runs fine, but if I pass a variable string path, I get undefined variable error.
<Papierkorb>
jwoertink, ECR reads the .ecr file at *compile* time, and actually embeds it right there. You can't do that at run-time, which is why using a variable won't work
<BlaXpirit>
jwoertink, this is a compile time construct, it turns the ecr file into code
<BlaXpirit>
a{{b}}c becomes io << "a" << b << "c" etc
<BlaXpirit>
or whatever the syntax for ecr is
<FromGitter>
<jwoertink> ah, so ECR.embed can only work inside of a macro
<FromGitter>
<jwoertink> err, when done like that
<BlaXpirit>
jwoertink, or, well, outside of a macro with a literal
<FromGitter>
<jwoertink> ok.
<FromGitter>
<jwoertink> Just when I feel like I have a grasp on macros, I run in to something that throws me off >_<
<BlaXpirit>
ECR.embed is a macro; macros can't get values of variables
<Papierkorb>
jwoertink, macros are from their semantics not far away from their C/C++ counterparts. Crystal macros offer more functionality, but other than that, they're actually expanded right there into the code
<FromGitter>
<jwoertink> I don't know C or C++ lol
<Papierkorb>
jwoertink, that's why you can (technically) access the local variables from the caller, and even modify them. They don't open a new scope like a function does, but are better compared to "copy pasting" their body there
<FromGitter>
<jwoertink> Macros to me are like airplanes. I have a very general idea of what they do, what they're used for, but every time I see one, it's still magic on how it works :joy:
<BlaXpirit>
yeah, saying it's easy would be lying
<FromGitter>
<jwoertink> Thanks for the clarification! At least gets me on the right track
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
<FromGitter>
<jwoertink> Looks like I can actually just use `ECR.process_file`, but one thing I'm a little confused on is passing in this buffer nam
<FromGitter>
<jwoertink> the output returns a string like `"io << \"whatever\"\n"`
<FromGitter>
<jwoertink> how do I use that string to push my io?
<FromGitter>
<bew> The returned string is the actual code that needs to be compiled
<FromGitter>
<jwoertink> but there isn't an `eval`, right? I saw a private method, but nothing like a `Kernel.eval` or anything
<FromGitter>
<jwoertink> I see in ECR the macro calls this `run` method. I'm not sure which `run` that is though. If it's `Process.run`, or `Crystal::Command.run`, or something else
<FromGitter>
<kazzkiq> I ran a simple (and not very useful) benchmark comparing Crystal and Node.js for a simple HTTP Server. In case anyone is interested in the results:
<FromGitter>
<jwoertink> That just seems like overkill. I just want to parse a ECR file
<FromGitter>
<eliasjpr> well you dont want to create 3 methods with different name that essentially do the same thing just need different args, I guess for the same reasons method overload exists :)
<DissonantGuile>
Papierkorb: I have an entity-component system I prototyped in Processing that I want to bring over to Crystal with crsfml, but it also has "Modifiers", which take a property name on a component and modifies it each game tick
<DissonantGuile>
I think I may be able to accomplish it using macros though
bjz has joined #crystal-lang
<Papierkorb>
DissonantGuile: You could have a macro which takes a bunch of property names (`macro meta_property(*names)`), which then generates a `meta_set(name, value)` method using a case statement to map a name to the actual property. See the getter and setter macros for inspiration, you can find those in Object (object.cr)
<Papierkorb>
DissonantGuile: Also see the `record` macro, also to be found in Object.
<DissonantGuile>
On the components? So a PositionComponent which adds #position would be defined with that meta_property and modifiers just call the meta_set? That's not a half-baked idea, I'll try that out
sz0 has quit [Quit: Connection closed for inactivity]
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bjz has joined #crystal-lang
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]