<FromGitter>
<watzon> How do you use `HTTP::Client.get` with a streaming API? I'm trying to connect to the Twitter streaming API (https://dev.twitter.com/streaming/overview/connecting), but I can't get it to actually display any data. It just blocks the thread
<Groogy>
aw man my first issue became a discussion :( thought it was a clear "this is just sometihng missing"
<Papierkorb>
Groogy: Welcome.
<Groogy>
I know it was naive of me :P
w-p has quit [Quit: Leaving]
Philpax has quit [Ping timeout: 255 seconds]
davidbe[m] has quit [Quit: Bridged client killed]
krigare[m] has quit [Quit: Bridged client killed]
snsei has joined #crystal-lang
mark_66 has quit [Remote host closed the connection]
rohitpaulk has quit [Ping timeout: 240 seconds]
snsei has quit [Remote host closed the connection]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 260 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 246 seconds]
sz0 has joined #crystal-lang
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 255 seconds]
Groogy2 has quit [Ping timeout: 258 seconds]
rohitpaulk has joined #crystal-lang
Groogy2 has joined #crystal-lang
Groogy has quit [Disconnected by services]
Groogy2 is now known as Groogy
Groogy_ has joined #crystal-lang
fenicks has joined #crystal-lang
<FromGitter>
<diegoaguilar> Hello, I was wondering about the present of Crystal in production, which are the big teams using it and what's the use case for a crystal project?
<FromGitter>
<bararchy> Hm.... I guess we should ping @ysbaddaden
<FromGitter>
<bararchy> It's hes repo, he is also the one working on alpine
pwned has quit [Ping timeout: 246 seconds]
A124 has quit [Ping timeout: 255 seconds]
pwned has joined #crystal-lang
<Groogy>
hmm there is nothing equivalent of send(symbol_var, *args) I am guessing?
<Papierkorb>
No there's not
<Groogy>
hmm need to figure out a good way to translate an input to a function call and data from the input to arguments to that call :/
<Papierkorb>
`case` statement
<Papierkorb>
which you may be able to auto generate even.
rohitpaulk has quit [Ping timeout: 268 seconds]
<Groogy>
Well that means I must already know what functions are available at a given time, but at different states various functions might not be available because the meaning of the input is different in that state
<Papierkorb>
Then build a proper state machine. it's the safer thing to do in any case.
<FromGitter>
<johnjansen> +1
<Groogy>
this is part of a state machine
<Groogy>
But it is a virtual input device of let's say controller or keyboard
<Groogy>
both who translates to the same action but different actions
<Papierkorb>
Then you already know all possible states at any time
<Groogy>
No the input virtual machine does not
<Groogy>
it's purpose is just to map input to a function
<FromGitter>
<johnjansen> there must be mapping rules though .. the functions dont just magically appear do they?
<Groogy>
no the functions would be part of an input processor, let's say a player entity which would have a jump function wheras pressing the A button would translate it into calling #jump
<Papierkorb>
Broken architecture in that case.
<Groogy>
This is how for instance the steam controller API works
<FromGitter>
<johnjansen> so you have a finite number of known actions
<Papierkorb>
Doing `#send` would be quite slow in a static language, and in a game, exactly not what you'd want
greengriminal has joined #crystal-lang
<Papierkorb>
Or well, not really about static languages, but rather, about the runtime environment
<Groogy>
for user input, performance overhead is not that bad and you can achieve this usually statically in C++ through templates
<Papierkorb>
In the simplest case, a hash mapping an action name to a proc suffices. Still has an look up cost.
<Groogy>
essentially this is what I am trying to replicate
<Groogy>
the problem with Proc as far as I can see, I can not have different signatures
<Papierkorb>
If you only have "do it" in term of action, there's not much else you need
<Papierkorb>
W pushed -> Go forward. W not pushed anymore -> Not go forward. A bool can do it. If you need analogue input, pass in a float too. they're cheap.
<Groogy>
yes but that means the go forward logic has to both recognize how to interpret moving forward digitaly and by analog data. Which this layer is supposed to remove
<Papierkorb>
Still, what you can do with C++ templates in terms of method invocation generation, you can do with macro code.
<Groogy>
which is also what the steam controller api removes
<Papierkorb>
Then just ignore the analogue input in the proc.
<Groogy>
that's not actually solving the problem just turning a blind side to it
<Papierkorb>
You haven't told us yet how you'd solve it in C++, or how a #send would've "solved" it
<Groogy>
Eh it's pretty complex but could link to the C++ code where I do similar thing with Ruby bindings?
<Papierkorb>
The problem is simple, thus a complex solution is too complex.
<FromGitter>
<johnjansen> +1
<FromGitter>
<johnjansen> i think you need to take a look at the problem with fresh eyes honestly
<Groogy>
it is possible in C++ thanks to specifically specialization of structures
<Papierkorb>
I mean really, input mapping isn't hard. A Hash(ButtonNameOrSo, Proc) would already do the job. Passing a non-used argument for some cases isn't a fault, especially if it's a float which costs nothing
<Papierkorb>
I don't see how dropping data in the caller as opposed to in the callee makes things much better
<Groogy>
No Proc doesn't work
<Groogy>
since you have to define a type
<Groogy>
i.e you have to define before hand acceptable input data to any of these logic that they have to interpret
<Papierkorb>
So?
<Papierkorb>
It's a button
<Papierkorb>
It's either on, or off
<Groogy>
Eh no
<Papierkorb>
It's a analogue input. it's a value between 0.0 to 1.0 - Or whatever. What other input methods are there?
<Groogy>
Let's say for moving forward, on a keyboard that data is digital while on our controller it's analogue. The game logic should implement the moving logic the same no matter what the input is. This is where the virtual input devicee comes in
<Groogy>
It's supposed to translate the two diffrent data to the same way
<Groogy>
It's how AAA games support ad-hoc plug-n-play of keyboard to controller
<Groogy>
i.e the moving forward code has no concept of actually input but only how do you move forward
<Papierkorb>
Yes. Both call the `mapping[key].call(triggered, value)` proc. In this case, it only cares that the input is held down.
<Papierkorb>
Not hard
<Papierkorb>
Which can then easily dispatch a `go_forward` "message" to the character object or something
<Groogy>
Yes but not every single input is simply one float value, or a binary state. You have the triggers on a controller, you have specific combinations of keys/buttons etc.
<Groogy>
As you actually apply it to real life scenario it isn't just "pass a float as an arg". I have the whole translation to an arbitrary data that can be splatted to a method. All I need is to be able to store references to a Proc of arbitrary arguments
<Groogy>
and I think I just figured out how
pwned has quit [Ping timeout: 240 seconds]
greengriminal has quit [Quit: This computer has gone to sleep]
greengriminal has joined #crystal-lang
<Groogy>
hmm I am trying to capture a block but it will tell me that there is no expected block if I try to use it, it's all fine if I don't actually touch the block :/
<Groogy>
but if I look at documentation that should work :/
<Papierkorb>
When capturing a block, always define its type
<Groogy>
hmm then I'm back to square one
<Groogy>
also the example should be fixed in the doc
<Papierkorb>
Not all data is created equal. But you can transform (in your case) among the different formats easily. Then you can easily map among the (as I see) three formats at runtime at low cost.
<Groogy>
yeah transformation and mapping is all done, it's just transfering it into a call in Crystal that I am trying to solve
<Groogy>
but yeah seems if you don't expect any arguments on the proc, you don't have to define the proc type either
w-p has joined #crystal-lang
<w-p>
can anyone explain in very plain terms the difference between a block, a proc, and a closure?
<w-p>
i've read through the docs a few times and looked over examples but am apparently still confused.
<Papierkorb>
w-p: Block: The block-of-code you can pass through `do .. end` or `{ .. }`. Proc: An anonymous function. You can optionally turn a passed block into a Proc. Closure: A proc which captures the scope it was created in to access or modify it.
<w-p>
thank you. that helps, i think. still processing.
<Papierkorb>
w-p: https://play.crystal-lang.org/#/r/2etl <- Consider this code for a moment. The method `#call_it` expects a Block, which we pass on line 7. The method then *catches* the block, turning it into a Proc (Line 1, the leading ampersand before `block` does this - Note that `block` as name is *not* special, you can call it what you want!). The method then goes on to calling the Block-now-turned Proc with an argument. Calling the Proc will
<Papierkorb>
take `some_num` from the scope it was created (So, the one active on line 7) from line 5, adds the passed argument to it (Effectively, `6 + 5`), and returns this result. We say the Block catches the scope, thus creating a Closure.
<Papierkorb>
So in this case, saying the `block` argument used on line 2 is a Proc, which in this case is also a Closure. We created the Proc/Closure by catching the Block.
<Papierkorb>
w-p: https://play.crystal-lang.org/#/r/2etq <- An example of a method returning a Closure. This pattern is much more common in e.g. JavaScript and functional programming languages.
<FromGitter>
<solisoft> Hi there I'm playing with C binding
<w-p>
like a lambda in python. got it.
<Papierkorb>
w-p: In other terms, a Closure is an anonymous function with a captured scope - The concept of it. A Proc is the implementation of that in Crystal.
<w-p>
Papierkorb: so is the `puts.call(5)` equivalent to `yield 5`?
<w-p>
Papierkorb: sorry, `block.call`...
<Papierkorb>
w-p: The concept is exactly the same. The only thing Ruby (and in turn Crystal) does extra is having the special Block syntax. So if you have a function in Python which expects something callable you'd pass in a lambda, in Crystal/Ruby, you'd use a block
<Papierkorb>
w-p: The concept is the same, but the use-case is not. `yield` is for not-caught blocks, `block.call` is for caught blocks (At this point, they're just Proc's)
<Papierkorb>
So, `block` is really just a Proc variable, and you're using Proc#call to call it
<w-p>
^ that helps a lot.
sz0 has quit [Quit: Connection closed for inactivity]
<Papierkorb>
solisoft, please gist at least the whole binding (The `lib` block), and the usage, and any output you get from the compiler or the program showing the full error message(s)
<Papierkorb>
w-p: First, fix the syntax, you have to tell it that you want it to be a `foo` taking an Int32: https://play.crystal-lang.org/#/r/2eva But then, a normal method doesn't have a closure, so you can't access `some_num` in there
<w-p>
right
<w-p>
so, you need to re-declare the method signature when passing a function/method as a proc?
<w-p>
ok, i see that in the docs, my bad.
<Papierkorb>
w-p: Usually, yes. The thing is this: Crystal is a *static* language, so the compiler always knows what type everything has. Your `foo` doesn't say what `x` can be, so the compiler will figure that out for you when you call foo. However, in this case, it won't be able to figure it out for you, so you have to tell it. You also have to do it if you're overloading `foo`, in which case the compiler would have again no idea which version to
<Papierkorb>
choose
<w-p>
the docs also show `foo = ->bar(Int32)` as proc assignment. so why is the ampersand needed there? because it's a block... which is a pointer to a proc?
<w-p>
i know i must sound like a neanderthal...
<Papierkorb>
w-p: `->foo` generates a Proc. `stuff(foo)` passes that foo as normal argument. But a block is no normal argument, so you have to turn it into a block by using the leading ampersand
<w-p>
Papierkorb: so then, a block is a thing, and a proc is a thing, and a closure is a thing, and a method is a thing. and what we're really talking about here is type casting. &->method_identifier == (block)(proc)method_identifier
<Papierkorb>
w-p: For toying it doesn't matter, but for real-code™, don't mix captured_block.call and `yield` in the same method. They're not entirely the same: The `yield`ing version will inline the block code if possible, whereas the captured-block version will not. In turn, the `yield` version will usually be slightly faster(-ish). Canonical is using `yield` except if you actually want to capture the block, e.g., to store the resulting Proc
<Papierkorb>
somewhere
<w-p>
hmm.
<w-p>
ok
<Papierkorb>
Closure is a concept, Proc is an implementation. Don't confuse that. And a block is more of "passed code logic", which you can catch, but don't have to.
<Papierkorb>
E.g.: `def foo; yield; end` <- Here, no proc is ever created.
<Papierkorb>
But blocks also refer to the scope they were defined in, so they too implement the closure concept. Maybe in other words: Blocks deal with "how to write logic" and Procs deal with "how to store logic".
<Papierkorb>
Of course, if you have written logic, you can store this logic by turning it into a proc.
<Papierkorb>
w-p: Though blocks are quite important, and are one of the main reasons (imho) that people refer to ruby (and crystal) as being elegant.
<Papierkorb>
w-p: E.g., the Enumerable module makes great use of them: `[1,2,3,4,5].map{|x| x * x}.select{|x| x > 5}` They allow you to write code that looks like it's operating on a stream of data, and instantly split your logic into smaller, more understandable chunks.
<w-p>
Ok. I think the part that has been confusing me is the analogue of a proc and an anonymous function / lambda. those a 'blocks' of logic assigned to an identifier. here, to pass a 'block' of logic, you need to assign it to an identifier (proc) and store it, but then to pass it you need to declare that it is in fact a block - prior to passing the identifier.
<Papierkorb>
Yes. But don't forget that a Proc is just a type. You can accept them as argument: `def foo(x); x.call(5); end; foo(->(x){ x + 1 })` works fine, and is something you'll see more in internal/private parts of your code.
<Papierkorb>
However, for front-end code it usually makes sense to accept a block. They're just so much easier to write, and easier to read. `foo(->(x){ ... })` is simply worse than `foo{|x| ...}`
<w-p>
Papierkorb: i _think_ that's looking more right-ish?
<FromGitter>
<bew> w-p there is also the non captured block concept, which allows blocks like `do ... end` or `{ ... }` to be inlined: https://play.crystal-lang.org/#/r/2ewg
<FromGitter>
<bew> Note that captured blocks (with the `&block : Type -> Type` notation inthe method signature) will never be inlined, they will always be turned into a proc
<w-p>
bew: awesome - thanks. this is really helping me out.
<Papierkorb>
w-p: Yes, prefer non-capturing over capturing if you don't need to capture. Other than that, the snippet looks about right.
<Papierkorb>
w-p: If you want to gain some little experience, you could try to write a simple sequential data structure (A linked list?), implement a yielding #each, and `include Enumerable`. Doing the last two things is all you need to do get most of the magic into your custom container :)
Philpax has joined #crystal-lang
greengriminal has quit [Quit: This computer has gone to sleep]