<rkeene>
Some things to consider: 1. It's running on my server and allows arbitrary code execution; 2. JavaScript closures are converted to Tcl lambdas so you can build NodeJS with no Node: http://www.rkeene.org/viewer/tmp/edonjs.js.htm
devil_tux has quit [Ping timeout: 246 seconds]
<rkeene>
Also, it's colorful if you do console.debug()
<rkeene>
and 3. It knows how to convert to/from Tcl data types: JSON.stringify(runtime.array.get('tcl_platform'))
<FromGitter>
<watzon> Oh nice :)
<rkeene>
It's a pretty interesting blend of two different languages that actually ended up working out
<rkeene>
runtime.after(1000, function() { console.debug('Running in the event loop'); }) that's the Tcl after(n) command ( https://www.tcl.tk/man/tcl8.6/TclCmd/after.htm ) running a JavaScript lambda that's been automatically translated
<rkeene>
There's even a C compiler thrown in there, in case you're into that sort of thing
duane has quit [Ping timeout: 246 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
ua_ has joined #crystal-lang
ua has quit [Ping timeout: 268 seconds]
go|dfish has joined #crystal-lang
rohitpaulk has joined #crystal-lang
DTZUZO has joined #crystal-lang
<FromGitter>
<mavu> I appologize in advance, but it is just too much fun to annoy /r/ruby people with mentioning crystal whenever sorbet comes up :)
laaron has quit [Remote host closed the connection]
laaron has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
alex`` has quit [Ping timeout: 272 seconds]
alex``` has joined #crystal-lang
<FromGitter>
<acoolstraw> hi
<alex```>
yo
<alex```>
Blacksmoke16 why crystal book is so slow to merge pr? :|
<FromGitter>
<acoolstraw> is there any 3D model of the crystal logo available?
<FromGitter>
<benrivero> I have been searching over Google and can't find a solution to this: I am making a report, on the Details part of the report there's a data that sometimes can have a lot of text. But this text doesn't show up
<FromGitter>
<Blacksmoke16> that doesnt work either
<z64>
include & extend works on instance methods of the parent module, not the class methods that class_* macros define https://carc.in/#/r/73mq
<RX14>
well, it does what extend does
<RX14>
you can never extend the class methods of an existing module
<RX14>
you need to create a module which you use with extend
<FromGitter>
<watzon> That's what I'm saying, I don't like that behavior. I know Crystal and Ruby are two islands, but Ruby allows the inclusion of everything, class and instance methods, properties, etc.
<FromGitter>
<watzon> Oh well
<RX14>
ary would be the one to answer that
<RX14>
but
<RX14>
i doubt it'll change
<FromGitter>
<watzon> I doubt it too
<RX14>
it's just one of those opinion things where sometimes you want to inherit cvars and sometimes you don't
<FromGitter>
<watzon> But it would be nice
<RX14>
we have the ability - albeit more verbosely with extend
<RX14>
it's just tradeoffs and speculation of common usecasesd
<RX14>
so making any change ends up not worth it
<FromGitter>
<watzon> Yeah
<FromGitter>
<watzon> Question, is there something existing in crystal that replicates Ruby's `enum_for
<FromGitter>
<watzon> Basically taking a method with a block and turning it into a method that spits out an Enumerable
<RX14>
no
<RX14>
there was talk of adding it but it'd involve using fibers and channels
<RX14>
and it was slow so it never got merged
<FromGitter>
<watzon> Ahh I see
<oprypin>
what do u mean using fibers and channels
<oprypin>
Nim is doing it without and is very well off
<RX14>
well you can do it with complex compiler state machine transforms, yes
<RX14>
do people care to add such complexity to the crystal compiler? no
<RX14>
I'm still amazed that the compiler without any caching techniques is as fast as it is
<oprypin>
im just saying, "google will never seriously consider it" is not a good place to be
<RX14>
Ok
<FromGitter>
<j8r> bazel is in Java :o
<RX14>
I'm not saying it's not important or I'm not keeping it in mind
<RX14>
But, it'll take a while
<RX14>
Its not a 1.0 blocking feature to be ready for google
<oprypin>
RX14, im somehow convinced that incremental compilation will never happen
<FromGitter>
<j8r> Why everyone talk about this, shared libraries are as important
<FromGitter>
<j8r> This will prevent to recompile project libraries
<RX14>
oprypin: I'm 50/50
<RX14>
Which aren't great odds
<RX14>
But what else can i do? Give up?
<RX14>
Not everything can be perfect
<oprypin>
do what's needed to ensure that it's possible, before it's too late
<RX14>
Yeah, that's what I've been pushing but nobody seems to listen
<RX14>
I know bcardiff wants it
<RX14>
And is probably the only one who can implement it in the near term
<RX14>
But he seems to always work on other things
<FromGitter>
<j8r> Is there a vote on Crystal, "what's youe most awaited feature?"
<FromGitter>
<j8r> I know there was one in 2017
<oprypin>
j8r, probably has been done before, but it's hard to make such a vote not biased
<oprypin>
the decision whether to group some semi-related features in the vote is hard
<oprypin>
(from what i remember, that was done poorly)
* FromGitter
* Blacksmoke16 most wants less broken generic inheritance
<FromGitter>
<j8r> We could open a forum post,
<FromGitter>
<watzon> Does the forum currently have a polling option?
<FromGitter>
<j8r> IMO that's important to have goals on par with the people expectations
<FromGitter>
<Blacksmoke16> prob
<oprypin>
i've probably said this before, but incremental compilation implies not being able to instantiate methods with types that haven't been used before
<oprypin>
j8r, eh in most OSS projects people just do what's interesting, anyway
<FromGitter>
<watzon> Ahh beautiful
<FromGitter>
<j8r> oprypin right, still when we have several interesting things :)
<oprypin>
RX14, so actually could the first step towards it be the ability for the compiler to instantiate methods less granularly / group things by nearest base class and such
<oprypin>
bah it's all been said before
<oprypin>
then someone says yeah but that's not backwards-compatible
<oprypin>
aha, so Nim doesn't have incremental compilation. nor surprising, they have all the same problems, and then some
<oprypin>
not*
<RX14>
oprypin: the key ability for me is to be able to type methods with fully specified type signatures
<RX14>
That's not something the compiler can currently do, and it should be able to
<oprypin>
I didn't understand that
<RX14>
Fixing that is a breaking change but an edge case one
<RX14>
One that people wouldn't notice much
<RX14>
That's what i want in before 1.0
<RX14>
It also improves a lot of things that other people complain about like uncalled methods not being type checked or compile errors being too long
<oprypin>
i didn't understand what you just said
<oprypin>
from the first sentence
<RX14>
I'm on my phone I'm not going to explain actually what the change is
<FromGitter>
<watzon> I'm curious too. what do you mean by "fully specified type signatures"?
lucasb has quit [Quit: Connection closed for inactivity]
hightower2 has joined #crystal-lang
<hightower2>
Hey, is there any crystal-preferred code repository platform other than github?
<FromGitter>
<watzon> Gitlab?
<FromGitter>
<watzon> Ok so is there any way to do this? ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ currently it fails with `can't use `yield` inside a proc literal or captured block`, which I don't get because `headers.each` is literally doing the same thing. [https://gitter.im/crystal-lang/crystal?at=5d0d358fbc834f76a4ba27fa]
<FromGitter>
<watzon> Well yeah I suppose I could do that for the sake of brevity. I just don't get why the second one works and the first doesn't.
<hightower2>
What does "->" do in a line "def files(&block : String ->)" ?
<FromGitter>
<Blacksmoke16> return type from a block
<hightower2>
yes, but which type is the return type ?
<FromGitter>
<Blacksmoke16> doesnt matter
<FromGitter>
<Blacksmoke16> would be more clear to do `String -> _`
<hightower2>
would it work if "->" wasn't specified at all?
<FromGitter>
<Blacksmoke16> im going to go with no
<FromGitter>
<Blacksmoke16> since then it wouldnt be a block restriction?
<FromGitter>
<watzon> > every_page.map(&.headers).each { |headers| yield headers } ⏎ ⏎ actually this doesn't work because `every_page` expects a block as well
<FromGitter>
<Blacksmoke16> wait really?
<FromGitter>
<Blacksmoke16> mm well makes sense i guess