<jhass>
no, crystal has chosen to only allow the direct modifier prefix, private def b
<FromGitter>
<alexherbo2> you think it's clearer?
<jhass>
(this is by design, not much point opening an issue at this point)
<FromGitter>
<alexherbo2> I hesitated between the two syntax in Ruby as they allow it
<jhass>
that was the consensus in some discussion iirc. I see the point as in (too) big Ruby classes I often get lost on whether I'm in the "private section" of it or not
<FromGitter>
<alexherbo2> Ruby 3 will allow setting variables at the right hand side
<jhass>
it also pushes me more into the clean code (as in the book) recommended principles of how to order methods within the class
<jhass>
yeah, I saw that. I hope they're not gonna push through with this
<jhass>
it's confusing to have too many ways to do the same thing. Ruby always had that problem, but at least it was mostly contained to stdlib until recently where they IMO overboard with the syntax changes
<FromGitter>
<alexherbo2> it could be nice to have it in Crystal?
<FromGitter>
<RespiteSage> I'm not familiar with Ruby, so I can't compare it, but that code is for sure a singleton pattern (a la Java).
<jhass>
singleton classes have little to do with the singleton pattern beyond the interpreter making sure there's only ever one instance of a particular singleton class
<jhass>
that's a recent trend around syntax changes in Ruby unfortunately
<FromGitter>
<RespiteSage> Oh, okay. I'll look up the term.
<jhass>
I'm not sure other languages beyond Ruby even have the concept, but it's one, if not the trick that makes Ruby's object model so beautiful IMO
<FromGitter>
<RespiteSage> I've just read up on it, and I can see how it works and why it's useful for the structure of Ruby itself, but I don't see how it's useful for an end-user. It seems like adding methods on a particular object would just be more confusing than helpful.
<jhass>
Yeah, it's something you shouldn't do per object creation, only for some program-lifetime objects it can sometimes be useful
<jhass>
but it's also a performance killer, so should be limited to program bootup
<jhass>
I just love it because it generalizes the whole "static method" buisness so nicely
<FromGitter>
<naqvis> forgive me rubyists if i misunderstood that, as I don't do ruby :P
<jhass>
naqvis: the big difference is in Ruby I could (I don't say should) do: foo = "hello"; def foo.bar; ...; end; foo.bar
<FromGitter>
<RespiteSage> Re the Ruby 3 link above: "For concurrency, they’ll avoid the solutions from other languages to try one of their own. ... Fibers ..."
<FromGitter>
<RespiteSage> Yes, *no other language* has done that yet.
<jhass>
every object has a singleton class, Class instnaces just happend to be some of them
<jhass>
tbf Ruby has Fiber's since idk, a very long time
<jhass>
`Enumerator` was always build upon them
<FromGitter>
<RespiteSage> They just didn't work truly asynchronously?
<jhass>
They don't run them on a thread pool, if that's what you mean
<FromGitter>
<RespiteSage> I'm just trying to understand what the difference will be in Ruby 3 if they have had fibers for a long time.
<jhass>
I haven't looked, if you had me guess probably some better stdlib integration
<jhass>
they weren't really utilized or integrated into stdlib beyond being the aforementioned implementation detail of Enumerator
<FromGitter>
<RespiteSage> In general, the improvements to the language sound like half-steps toward what Crystal already does: improved performance with JIT compilation, async fibers for faster I/O, and a little bit of pre-runtime type checking.
<jhass>
well Ruby will never (be able to) move to quite what Crystal is, nor will Crystal never (be able) to move to what Ruby will become quite
<FromGitter>
<naqvis> yeah and totally agree with jhass. Crystal ain't Ruby and Ruby won't be Crystal :P
<FromGitter>
<RespiteSage> Yeah, I'm definitely with y'all there.
<jhass>
so yeah, context quote from above is actually "long-awaited async i/o “fibers”", so that sounds like actually integrating the coroutine's with stdlib IO, much like Crystal, Node or Go do
<FromGitter>
<RespiteSage> So it's less of a language feature and more of an effort to integrate it into the stdlib.
<FromGitter>
<RespiteSage> \*less of a *new* language feature
<jhass>
I would think, probably they'll also investigate the whole run fibers on a threadpool buisness, which is sort of on the border between VM runtime and stdlib
<jhass>
but certainly implementable as a library, as falcon & co demonstrate
<FromGitter>
<roduquen> Hi I have a problem with websockets, ⏎ I explain : ⏎ I create a websocket server with websocket handler, ⏎ When I connect with Crystal to the websocket, everything goes well, but when I try to close websocket that are done with Javascript, the on close function is never called, the websocket is never deleted [https://gitter.im/crystal-lang/crystal?at=5f4e633249a1df0a12bff250]
<FromGitter>
<roduquen> and even if I call explicitely socket.close
<jhass>
maybe you're blocking the fiber somehow waiting for the close event?
<jhass>
-Dpreview_mt making things better or worse should be an easy litmus test for that
<FromGitter>
<roduquen> I am not sure I understand, can I send you part of the code ?
<jhass>
see if the bug still happens with crystal build -Dpreview_mt
<FromGitter>
<roduquen> Oh ok I didn't understand
<FromGitter>
<roduquen> I relaunch the dockers
<FromGitter>
<roduquen> Yes always nerver called
<FromGitter>
<roduquen> Oh sorry I removed the pute
<FromGitter>
<roduquen> I try again
<jhass>
well, I'd suggest you try to build a minimal example that reproduces the bug that you can share
<FromGitter>
<roduquen> I create a new image, it will take few minutes
<FromGitter>
<roduquen> I have an issue with shards what I have to write instead of "crystal: 0.35.1 ⏎ " ? nightly ?
<jhass>
'>= 0.35.1' should do
<jhass>
or just use your self contained example that doesn't depend on any shards?
<FromGitter>
<roduquen> It works
<FromGitter>
<roduquen> :/
<jhass>
great!
<jhass>
so Crystal 1.0 will fix it :)
<FromGitter>
<roduquen> It seems that it works inside the box but with the 0.35.1 it works too
<FromGitter>
<roduquen> .. sorry
<FromGitter>
<roduquen> Can I develop all the timeline to websocket
<jhass>
Sorry, I didn't get that. Could you rephrase?
<FromGitter>
<roduquen> Can I expose all the journey to the on_close
<FromGitter>
<roduquen> It is not too big
<jhass>
uff, probably only by editing the stdlib code
<FromGitter>
<RespiteSage> Could you use a debugger for that?
<FromGitter>
<RespiteSage> I've not used the new debugging stuff yet, but that seems like the kind of problem that a debugger would be suited for (if it works yet in Crystal).
<jhass>
our debug info is still a bit rough around the edges, but generally yes, you could use gdb or lldb
<jhass>
and compile with --debug
<jhass>
50/50 chance it's more useful than plain ol' print debugging at this point tbh
<FromGitter>
<RespiteSage> To clarify, "isn't working" means "causes an error during compilation which lists `/` as one of the possible expected tokens".
<FromGitter>
<RespiteSage> It seems like it's parsing the `/` in `def self./` as the beginning of a regular expression instead of as an operator method name.
<jhass>
probably a bug, nobody having thought of doing something a weird as a class method / sounds reasonable :P
<FromGitter>
<RespiteSage> Yeah, I could see that. Do you think it's worth a forum post as an intermediate step, or should I just make an issue?
<jhass>
just make an issue, it's a parser bug :)
<FromGitter>
<RespiteSage> Alright, I've done so. Not really a huge behavior issue, but hopefully it'll just be one more thing that isn't unexpectedly broken for new (and very strange) users.
<jhass>
It's one of the things MakeNowJust tends to fix within a week or so :D
tsujp has quit [Ping timeout: 264 seconds]
<jhass>
or Ary within a couple of hours xD
<FromGitter>
<Blacksmoke16> couple minutes* ha
<FromGitter>
<RespiteSage> "This is very difficult" *two minutes pass* "Actually, this is very easy. I've done it."
<FromGitter>
<j8r> @roduquen how do you close the websocket? What's the `onclose`, in JS or Crystal?
baweaver has joined #crystal-lang
<FromGitter>
<RespiteSage> How do you loop on a condition in a macro (since `while` and `until` aren't allowed)?
<oprypin>
RespiteSage, you cant. just have to write an {% if %} in a way that the condition will no longer be true ever
<FromGitter>
<RespiteSage> Maybe I'm asking about what I perceive as the only solution instead of my actual problem. I'm trying to simultaneously filter two arrays "against" each other in a macro. The algorithm is this: https://carc.in/#/r/9md0
<FromGitter>
<RespiteSage> Basically, I'm "cancelling out" things between the arrays. I can't just use `#select` because it will remove all instances of an element when I only want to remove one.
<FromGitter>
<Blacksmoke16> create a new array, iterate over each array and add elements to the new array?
<FromGitter>
<Blacksmoke16> you can do some things to simulate `while` loops in macro land
<oprypin>
RespiteSage, i think you gotta start by rewriting this as.. arr1.each_with_index do arr2.each_with_index do 🤣
<FromGitter>
<Blacksmoke16> you can do that in macro land
postmodern has joined #crystal-lang
<oprypin>
is there really no way to skip `postinstall` for `shards`?
<FromGitter>
<RespiteSage> I'm pretty sure my algorithm is in a better complexity class than the O(n * m) of that idea, but it occurs to me that it's unlikely that each array would have even 20 items, so it doesn't really matter.
<oprypin>
RespiteSage, of course but macros arent turing-complete (in reality they probably are but through some super obscure stack machine or some shit) so you'll have to make do
<oprypin>
im actually not sure if my n * m suggestion would even be applicable
<oprypin>
fucking shards, man. yet another time where i have to skip it and directly use git instead
renich has joined #crystal-lang
renich has quit [Remote host closed the connection]
renich has joined #crystal-lang
<FromGitter>
<roduquen> @j8r Ok I solve the problem I am not sure it is important for you to know, my problem was into a fiber, and now the problem is done, the only thing I did is put a begin+rescue inside each method for websocket, there was 0 execptions raised before, but by putting everything into a block begin rescue, it solved the problem, I don’t understand why becausebefore no exception were raised, and now no exception are
<FromGitter>
... raised too, but it solved the problem
<FromGitter>
<roduquen> The on_close in crystal was juste a puts + unsubscribing to channel, and even if I did socket.close it didn’t call the onclose
<FromGitter>
<roduquen> in js it was with react was just a close inside the componentWillUnmount
<FromGitter>
<roduquen> The onclose in js was a console.log and it was working well
<FromGitter>
<roduquen> i find other problem with that on close in js, sometime connection were closed instantly before I put the begin rescue blocks
<FromGitter>
<j8r> Didn't have such issue yet
<FromGitter>
<j8r> The only thing I got yet is when you stop the server, the connections are not gracefully closed
<deimos_>
hi, a+ for crystal ease and performance. I re-wrote a python monthly report generator in crystal. the python took 3 months at a contractor, i did it in 2 weeks. and it worked.
<FromGitter>
<Blacksmoke16> 👏
<deimos_>
a question, the slowest part of the report is rsync to 500+ server to grab the app log file
<FromGitter>
<j8r> noice!
<deimos_>
for performance, it also runs in 1.5h versus the python report ran in 6-7h
<FromGitter>
<j8r> ha, why not having a push instead of pull for the logs?
<deimos_>
it's a long story, but pull is the best we have now
<FromGitter>
<j8r> also, you could spawn fibers/sub process do to the pull of logs
<deimos_>
that's what i was going to ask, my spawn is failing or not working like i thought
<FromGitter>
<j8r> failing? Note that is the operation is IO bound, spawning multiple fibers won't help much
<deimos_>
basically, i run spawn do (stuff here to pull logfile); (stuff here to parse logfiles); (stuff here to write to db) end; fiber.yield
<deimos_>
it seems to run serially, not parallel-ish like i thought
<FromGitter>
<j8r> Fiber.yield? You probably don't need it
<FromGitter>
<j8r> Likely because the operations are IO bounds
<FromGitter>
<j8r> spawn is useful for light tasks
<FromGitter>
<j8r> If each operation is independent, the best would be to create sub processes. ⏎ If you have 4 cores, create 4, etc
<FromGitter>
<j8r> there is also multi-thread, but that won't be as fast
<deimos_>
my naive thought was to use fibers like threads and just create hundreds and let the OS figure it out
<deimos_>
fwiw, i re-wrote it in ruby originally, and used the parallel gem to get the same result
<deimos_>
but ruby log parsing, like python, is super slow compared to crystal. and forcing me to deal with nil cases before running actually makes code better
deavmi has joined #crystal-lang
deavmi_ has quit [Read error: Connection reset by peer]
<deimos_>
also, now that the crystal report gen works without errors and so fast, i can do this daily, rather than monthly
<FromGitter>
<j8r> yeah but multi-thread are less efficient of multi process, because of shared memory and context switch
<deimos_>
that would mean using the Process class?