teardown_ has quit [Remote host closed the connection]
teardown has quit [Ping timeout: 240 seconds]
teardown has joined #crystal-lang
chovy has joined #crystal-lang
<chovy>
is there a good cross platform gui tool kit?
<chovy>
i want to build a simple desktop app for win/mac/linux
postmodern has joined #crystal-lang
<chovy>
man nothing on udemy for crystal programming language
repo has quit [Ping timeout: 272 seconds]
repo has joined #crystal-lang
<oprypin>
lol
<chovy>
is this language going to take off?
<postmodern>
shardbox.org really needs a "Parser Generator" category. Was trying to research which parser libraries are popular. All I know is Pegasus. Not sure if there's any bison/flex crystal adaptations.
<FromGitter>
<jrei:matrix.org> that's a detail, strange to use classes for the immutables objects like Map and Vector
<FromGitter>
<jrei:matrix.org> that's copy on write :)
HumanG33k has joined #crystal-lang
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
teardown has quit [Ping timeout: 240 seconds]
teardown has joined #crystal-lang
f1reflyylmao is now known as f1refly
deavmi has quit [Ping timeout: 272 seconds]
deavmi has joined #crystal-lang
hightower2 has joined #crystal-lang
<FromGitter>
<watzon> Is there a more convenient way to concatenate bytes slices than writing them to an IO? Because I haven't been able to find one, but creating an `IO::Memory` every time I want to add a couple slices together is getting annoying.
<FromGitter>
<watzon> I know a more performant thing would also probably be to create an empty byte slice and memcopy the other slices to it, but meh
<oprypin>
obskyr is somewhat high-profile. seems like they got turned off by something
<FromGitter>
<watzon> Honestly this has been one of my main problems with Crystal lately is how quickly new ideas seem to get shut down, a lot of the time without any real discussion. From the get-go a core maintainer will be like "well I don't like this" and then others jump on board, someone says "this isn't a priority", and the issue gets closed. When I initially started getting involved in the community some 5 years ago it seemed
<FromGitter>
... a bit more welcoming, but now I can't tell you how many people I've talked to that have been turned off of the language simply because they felt unwelcome. Obskyr's issue history is a perfect example of that.
<FromGitter>
<watzon> Nim and Zig have the exact opposite thing going on. Ideas definitely get shut down, and often, but at least there's a real discussion where people feel like they're being heard.
HumanG33k has quit [Remote host closed the connection]
<FromGitter>
<Daniel-Worrall> Feels like there's a lot of discussion going unshared in the private core dev chat rooms
<FromGitter>
<watzon> Same
<FromGitter>
<watzon> This is all very disappointing to me for several reasons, the core one being that I still love the language and want it to succeed. It's hard to succeed in isolation, and it's hard to succeed when you're ostracizing community members that are trying to do their best to help make the language better.
<FromGitter>
<Blacksmoke16> i mean, got a recent example of a new idea being shut down without discussion?
<straight-shoota>
^ would be interested in that, too
<straight-shoota>
I really have a different perception, that lot's of ideas are hanging in limbo and no-one decides whether to go on or drop it
<FromGitter>
<Blacksmoke16> ^, thats what i see more of too
<yxhuvud>
would be really nice to have a release though. Half a year without a release is too long, regardless of if they want the next to be 1.0 or not. RCs would be fine in that case, just release something.
<straight-shoota>
definitely
<FromGitter>
<Blacksmoke16> theres a PR for it created like a month ago
<FromGitter>
<Blacksmoke16> :/
ua has quit [Ping timeout: 264 seconds]
<FromGitter>
<Blacksmoke16> almost 2 now*
<FromGitter>
<watzon> That's another issue. Looking for a more recent example of what I was talking about. Obskyr's issues are pretty good examples, but maybe it's just my perception based on what I find every time I search for an issue and find that it already exists and was already closed. What would be nice to have is a voting system for issues so we can get a feel for what the community as a whole actually wants. Github issues
<FromGitter>
... aren't great at that, even with reactions.
<FromGitter>
<Blacksmoke16> i wouldnt call those recent tho, and they all have 10+ comments
<FromGitter>
<Blacksmoke16> its not like it was "i dont like this", (close)
<FromGitter>
<watzon> https://github.com/crystal-lang/crystal/issues/9673 this is a good example actually. There's been more than a few times I've been annoyed with the built in string manipulation methods myself, including camelcase.
<FromGitter>
<Blacksmoke16> > Or maybe create a shard for more specific (and performant) string operations.
<FromGitter>
<watzon> The "if you don't like it make your own shard" argument is one I've seen a few times. While it might be trivial to roll your own camelcase method, why not try to do it right in the standard library?
<FromGitter>
<Blacksmoke16> i guess its a balance of what is useful versus what would just be bloat
<FromGitter>
<Blacksmoke16> like the stdlib isnt intended to be "everything you may ever need"
<straight-shoota>
thanks for picking one I starred in =)
<straight-shoota>
My take is that stdlib should be a sound foundation for most common features and be easy to use
<FromGitter>
<watzon> Just happened to be one of the latest closed issues marked with feature request haha
<straight-shoota>
I'm totally concinved I shouldn't have closed it right away
<straight-shoota>
it realls feels like surpressing discussion
<FromGitter>
<Blacksmoke16> fwiw you did close it 3 months after your comment
<straight-shoota>
oh, right
<straight-shoota>
never mind then :D
<FromGitter>
<watzon> I agree with keeping bloat down to a degree, but at the same time this language is meant to be convenient and easy to use. There are also a large number of people that move here from Ruby that are use to a somewhat "bloated" standard library. I just think it would make sense to implement some kind of voting system so we can at least get a sense for how the community at large feels.
ua has joined #crystal-lang
<FromGitter>
<Blacksmoke16> possibly, but also would be quite biased imo
<FromGitter>
<watzon> Maybe a combination of that and a bot that closes stale issues automatically after giving a warning. That way people can have a chance to get the conversation going again, and if they don't the issue gets closed. Pretty sure Dart and a few other languages I've played with use that.
<FromGitter>
<watzon> Biased how?
<FromGitter>
<Blacksmoke16> as the saying goes "squeakiest wheel gets the oil"
<FromGitter>
<watzon> Well yeah, but usually the squeakiest wheel is the one that needs the oil the most, no?
<FromGitter>
<Blacksmoke16> an example would be windows, sure it would be nice to have (as would prob a large portion of people), but to me personally i dont really care about it as i dont use windows
<FromGitter>
<Blacksmoke16> id rather work on an annotation refactor
<FromGitter>
<watzon> Obviously the people actually writing the code would get final say on what gets implemented, but it would be a better way to get a feel for what the community wants. Github issues can be intimidating.
<FromGitter>
<Blacksmoke16> but in the end there isn't really a need as its open source
<FromGitter>
<Blacksmoke16> its not like you can force a non core dev to work on something other people voted on
<FromGitter>
<watzon> @Blacksmoke16 same, but currently there's no way to know how many people actually want Windows support. I imagine there are quite a few, but it's hard to gauge just based off the issues.
<FromGitter>
<Blacksmoke16> pretty sure its the most 👍 issue
<FromGitter>
<Blacksmoke16> forgot the is:open filter
<FromGitter>
<Blacksmoke16> im hoping there'll be more of a roadmap after 1.0.0 is released
<FromGitter>
<Blacksmoke16> as i imagine brian and other manas core devs are focusing on that
<FromGitter>
<Blacksmoke16> from there you could have like "this is what we want to get done in Q1 2021" then could have a voting thing to determine the priority
<FromGitter>
<watzon> That would be a nice thing to have
<FromGitter>
<watzon> Since we'll be hitting v1.0 it would be great to get an actual release schedule
<straight-shoota>
i know they have used such plans at manas internally
<straight-shoota>
and shared with the core team
<straight-shoota>
but yeah, making these things public and possibly getting more people involved would be great
<FromGitter>
<watzon> Exactly. I don't understand keeping it all private. This is an open source project with a pretty nice community, it would make sense to share things and enlist support. Could probably get things done a lot faster.
<straight-shoota>
it just needs some other bugs figs to be useful
<FromGitter>
<watzon> Man I'd still love to be able to actually traverse and modify the AST at compile time like you can do with Nim rather than just some rudimentary codegen. A man can dream.
<FromGitter>
<Blacksmoke16> what ever became of the error handling refactor you were doing?
<straight-shoota>
unfortunately, those bugfixes probably require some more extensive refactoring
<straight-shoota>
hah, yeah
<straight-shoota>
I postponed it because I figured it wouldn't fit into 1.0
<straight-shoota>
initially, I thought it would be a big change, but not actually hard to do. But devil is in the details. Lot's of code depends on current quirky behaviour
<straight-shoota>
In retrospec, I probably should've continued with it and it would have fit very well in the time frame since we still haven't reached 1.0
<FromGitter>
<Blacksmoke16> at this rate we'll get to 2.0 first
<straight-shoota>
rofl
<straight-shoota>
might be an intersting swing
<FromGitter>
<oz:matrix.org> this makes me think that maybe Crystal could have something like Nim's fusion repository to "stage" new ideas before they could be added (or not) to the stdlib?
<FromGitter>
<mattrberry> Is it known that runtime exceptions don’t always point to the place they happened when compiled for release? It makes debugging my emulator tricky when I get an arithmetic overflow and can’t even tell which file it’s from :p
<FromGitter>
<watzon> Might not be a bad idea
<FromGitter>
<Blacksmoke16> compile with `--debug`?
<straight-shoota>
mattrberry, the problem is that release builds are highly optimized and lots of function calls may just be inlined, so it's not straightforward to get accurate backtraces
<FromGitter>
<Blacksmoke16> > Related to language, compiler, tools and standard library. Let’s talk about how/if something should be added/changed/removed.
<straight-shoota>
it's basically an extended stdlib
<FromGitter>
<mattrberry> @Blacksmoke16 Isn’t the —debug flag on my default, even in release? That was my understanding, but I’m not at my computer atm
<FromGitter>
<mattrberry> @straight-shoota That makes sense :/ I wish my gba emulator could run at full speed when not in release, because otherwise it takes ages to get to the point that it crashes :p
<FromGitter>
<watzon> Yes but also no. That's just a place for dicsussion, what @oz:matrix.org is talking about is an actual branch that's purpose built for testing potential changes. Kind of like Rust's nightly builds.
<FromGitter>
<watzon> That would be a nice thing to have as well
<straight-shoota>
it's in the same ballpark as +
<FromGitter>
<jrei:matrix.org> or, using `+=`
<straight-shoota>
or maybe not, it should be mutating
<FromGitter>
<jrei:matrix.org> I think, first split the shas, then concat, to make it clear
<FromGitter>
<watzon> Yeah I definitely agree that any methods that are generally self-mutating should be left out
<straight-shoota>
general suggestion: `auth_key[x..(x + 36)]` could be `auth_key[x, 36]`
<FromGitter>
<watzon> If we can decide on exactly what we want implemented I can submit a PR to get things moving. I don't imagine it would take more than an hour worth of work to get the concatenation methods added and tests written.
<FromGitter>
<watzon> @straight-shoota ahh you're right. Translating some of this from Python, so there's definitely some cleanup to do.
<straight-shoota>
yeah, implementation shouldn't be hard at all
<FromGitter>
<jrei:matrix.org> Slice#concat(*slices) can be very useful
<FromGitter>
<jrei:matrix.org> not take just one, but multiples
<FromGitter>
<Blacksmoke16> `Slice.join(*slices)`
<FromGitter>
<watzon> Tbh even `IO::Memory` having a constructor that accepts multiple byte slices would be acceptable to me, but I feel like that's mostly just useful in my current situation.
<FromGitter>
<jrei:matrix.org> @Blacksmoke16: yes but no, the point is to keep an existing slice and grow it
<FromGitter>
<Blacksmoke16> so id think it would work like `Time`. I.e. you get a new slice that is `*slices` merged into one
<FromGitter>
<jrei:matrix.org> yes, but I expect Slice.join creating a new buffer
<FromGitter>
<jrei:matrix.org> not mutating the first one
<FromGitter>
<Blacksmoke16> right, thats what it would do
<FromGitter>
<jrei:matrix.org> IO::Memory mutates its internal buffer
<FromGitter>
<jrei:matrix.org> so, performance wise, better using IO::Memory than using Slice.join
<FromGitter>
<watzon> Yeah, it would create a new buffer that's the size of the combined size of all the other slices, and then copy those slices into it using `Slice#copy_to` I imagine.
<FromGitter>
<jrei:matrix.org> that's why I like `Slice#concat`, but `Slice#+` can be useful too
<FromGitter>
<watzon> Well `IO::Memory` and `Slice.join` would both have to create a new buffer though, no? Unless you already had the `IO::Memory` and you're adding to it.
<FromGitter>
<watzon> @straight-shoota I would see that as a reasonable compromise if the core team doesn't want to add the Slice methods for whatever reason. Not as pretty, but at least it works.
<straight-shoota>
when Slice gets #+, it should also get .additive_identity (after #10151 is merged)
<straight-shoota>
Enumerable#sum would just be a byproduct, I'd still have something like concat
<FromGitter>
<watzon> Ahh nice
<FromGitter>
<watzon> I was gonna say, both would be better haha
<straight-shoota>
as in an explicit API
<FromGitter>
<jrei:matrix.org> after thinking more, adding `IO::Memory#write(*slices)` will some your verbosity issue @watzon:
<FromGitter>
<jrei:matrix.org> really, the difference between the two examples is one operation per line vs multiple operations per line
<straight-shoota>
still, I don't think you should be bothered to create an IO if you just want to concatenate some slices
<straight-shoota>
it's a different mental model, and yes you can bend to make it work, but having a clean and concise way is better
<FromGitter>
<watzon> I agree completely. Until then I'm monkey patching `IO::Memory.new` to accept multiple slices as an input, and that should cut down on verbosity, but I'd love to have slice concatenation.
<FromGitter>
<jrei:matrix.org> maybe, but with Slice#+ lots of intermediary slices will be created
<FromGitter>
<jrei:matrix.org> `one + two + three` == `((one + two) + three)` . Here, one intermediary slice. And will go up if more concat is done
<oprypin>
> when Slice gets #+, it should also get .additive_identity
<oprypin>
no it shouldnt O_o
<FromGitter>
<Blacksmoke16> what about `slice1 + 12_u8` :trollface: l
<FromGitter>
<Blacksmoke16> does that add a byte on the end and return a new slice?
<straight-shoota>
@jrei:matrix.org: There's also `String#+` even if you could just use a IO::Memory to save intermediaries
<FromGitter>
<jrei:matrix.org> so, @Blacksmoke16 's proposal of `Slice.join(one, two, three)` is not bad, but will be like `IO::Memory.write(one, two, three)`
<straight-shoota>
and there's even a convenient syntax using string interpolation
<Andriamanitra>
watzon: python's "x in arr" is just a nice way to say "arr.__contains__(x)" and not a real method like Object#in?
<FromGitter>
<watzon> `in` in python is an operator which basically searches a collection for an object. So it's very similar, but they are different since `in` is a built-in in Python.
<FromGitter>
<watzon> Thanks @oprypin, didn't even realize that `Pointer` has a `+=` op
<oprypin>
watzon, in crystal `+=` is always `=` and `+` (unlike in python with its list extend trap, grumble grumble)
<Andriamanitra>
it's just a matter of perspective which one you consider a trap.. python's __iadd__ gives you the performance you'd expect from in-place addition
<oprypin>
i have .extend for that, thanks
<Andriamanitra>
and i have x = y + z for the other thing :p
<oprypin>
enjoy writing a[x] = a[x] + [y]
<Andriamanitra>
that's modifying original a anyway?
<oprypin>
it's not modifying original underlying a[x] which is a list
<Andriamanitra>
fair enough
<hightower2>
watzon nice that you took the effort to reopen += thing
<hightower2>
thanks
<FromGitter>
<watzon> carc.in really needs to be updated to support the if suffix syntax. `foo = bar if baz` leads to it thinking the indentation level should be elevated.
<FromGitter>
<Daniel-Worrall> test
Nekka has left #crystal-lang ["Leaving"]
<FromGitter>
<Daniel-Worrall> test 2
Nekka has joined #crystal-lang
<FromGitter>
<Daniel-Worrall> oops
<hightower2>
Hey could help me review a macro... I have these two macros which work: https://carc.in/#/r/a6y3
<hightower2>
But they fail if the function to be aliased ends with =... https://carc.in/#/r/a6y6
<hightower2>
I'm not sure where/what exactly needs to be adjusted