<FromGitter>
<asterite> rotate! Is a different optimization than shift, and it wasn't done by me
postmodern has joined #crystal-lang
<FromGitter>
<franciscoadasme> hey everyone, quick question, how could I generate N unique random integers within a given range without creating the entire list of possible numbers first? I couldn't find a simple way... in python, I could do `random.sample(range(int(1e12)), 10))` where `range(n)` is not a list of values but rather similar to a range in crystal
<FromGitter>
<Blacksmoke16> do you want to make an array of of these values?
<oddp>
But it's an enumeration, isn't it? Not an iterator.
oddp has quit [Quit: quit]
<FromGitter>
<franciscoadasme> uhm `Enumerable.sample(n)` might work... I was looking to something simple like that
<FromGitter>
<franciscoadasme> I see that the impl. of `Enumerable.sample(n)` iterates over every element, so if the collection is large, it takes a lot of time
<oprypin>
franciscoadasme, yea that sucks
<FromGitter>
<franciscoadasme> I tested `(0..1_000_000_000).sample 10`, and it takes over 40 seconds... this `(random.sample(range(1_000_000_000), 10))` in python is almost immediate
<FromGitter>
<franciscoadasme> thanks... it seems that it's the best way for now
<oprypin>
franciscoadasme, it's the best way always, just that currently it doesnt happen to be in stdlib
<FromGitter>
<franciscoadasme> yes, that's what I meant
deavmi has joined #crystal-lang
oddp has joined #crystal-lang
<oddp>
"best way always" -- tell this to my friends over at dlang. `iota(1, 1_000_000_000).randomSample(10)` makes use of vitter's reservoir sampling. :D
dom96 has quit [Quit: Nim is King]
<raz>
oprypin: but. if you are very unlucky, you code may never complete. :p
oddp has quit [Quit: quit]
<FromGitter>
<watzon> This is much faster `10.times.map { rand(0..1_000_000_000) }.to_a`
<FromGitter>
<watzon> Or just `Array.new(10) { rand(0..1_000_000_000) }` is probably better
<repo>
is it possible to have crystal unescape them automatically?
<FromGitter>
<naqvis> don't think stdlib should be taking care for such cases, so you should be uncapping the fields yourself by invoking `HTML.unescape` which requires to be unescaped.
<repo>
HTML.unescape doesn't work for that
<repo>
i would need to read the hexcode and turn it into a char
<FromGitter>
<Dan-Do> I find rare information on google regarding libevent2-devel
<straight-shoota>
libevent2-devel is the development package for libevent2. I have no idea how to install that on fedora
<straight-shoota>
but this really shouldn't have changed from 0.35.1
<FromGitter>
<Dan-Do> I am using crystal 0.35.1 normally, it's strange
<straight-shoota>
so what are the dependencies of the installed crystal package?
<FromGitter>
<asterite> I think it would be fine for `strip` to remove unicode whitespace. It's probably slightly slower than only checking ascii, but it's more correct
avane has joined #crystal-lang
oddp has joined #crystal-lang
<oddp>
@Dan-Do, why are you using el6.x64_64 on fedora? the all.x86_64 works find when you install libevent-devel from the repo.
<oddp>
fine*
<oddp>
Did that just yesterday.
<FromGitter>
<Dan-Do> Yeap, would give it a try. Have no idea what is the difference between that 2 el6 and all :)
<FromGitter>
<Sija> > I think it would be fine for `strip` to remove unicode whitespace. It's probably slightly slower than only checking ascii, but it's more correct ⏎ ⏎ @asterite yup, that’s IMO the most expected outcome, `blank?` checks for unicode whitespaces too
<yxhuvud>
straight-shoota: ok, that explains how it ended up like that. Personally I'd still prefer it to return whateer the matching syscalls returns, but I suppose it may be hard in some cases (like, buffered io)
<yxhuvud>
like, suppose you write to a disk that becomes full halfway during the write. How is that handled?
<straight-shoota>
yes that's the idea behind #9186. It's just hard to implement correctly
<yxhuvud>
I suppose an exception could be the right answer. it is pretty exceptional after all..
<straight-shoota>
yeah
<yxhuvud>
though not for the read case where reading what is available is a very common thing to do. I guess it is hard to make a one size fits all.
postmodern has quit [Quit: Leaving]
postmodern has joined #crystal-lang
Volk has joined #crystal-lang
Volk has quit [Client Quit]
<postmodern>
based on a question from Twitter, is it possible to convert a Int128 into a Byte slice? I tried to use unsafe_as, but got an arithmetic error https://play.crystal-lang.org/#/r/abd7
<yxhuvud>
IO::ByteFormat::something is problably what you want
issyl0 has quit [Ping timeout: 246 seconds]
melthelesbian_ has quit [Read error: Connection reset by peer]
willamin has quit [Ping timeout: 272 seconds]
jetpack_joe has quit [Read error: Connection reset by peer]
r0bby has quit [Read error: Connection reset by peer]
sz0 has quit [Read error: Connection reset by peer]
Liothen has quit [Read error: Connection reset by peer]
entel has quit [Read error: Connection reset by peer]
<yxhuvud>
that said, I wonder why the sandbox is so restrictive on stacktrace info. Is it intentional? I get positions for everything locally (though the line number doesn't actually match the method it claims is called, which is a bit odd)
jetpack_joe has joined #crystal-lang
Liothen has joined #crystal-lang
issyl0 has joined #crystal-lang
<FromGitter>
<jwoertink> Anyone noticing a really REALLY slow process running `crystal spec` on 0.36?
<FromGitter>
<jwoertink> I just installed it from brew on Mac (not M1), and it took almost 10minutes before the first green dot showed up.
<FromGitter>
<jwoertink> 2 minutes later, and I think I'm now 4 specs in
<FromGitter>
<jwoertink> Ah, interesting. So I ran the spec suite again, and it finished super quick like I'd expect. The whole thing in about 3 seconds. Then I deleted my `~/.cache/crystal/` and tried again, and it's back to mega slow
<postmodern>
yxhuvud, ah weird. Yeah `i = 0_i128; i = i - 1`
<straight-shoota>
@jwoertink, for entire spec suite you need to compile a file with content `require "./spec/**"`.
<FromGitter>
<jwoertink> 👍
<FromGitter>
<jwoertink> oh wow... I think it's the building that's taking so long
<FromGitter>
<jwoertink> Cleared cache, and `crystal build spec/spec_runner.cr`, and it's 3minutes in and still building
<FromGitter>
<jwoertink> now to see if it's doing this on a normal crystal file
postmodern has quit [Remote host closed the connection]
postmodern has joined #crystal-lang
sz0 has joined #crystal-lang
<postmodern>
ugh looks like 0.36 broke digest-crc. Apparently Digest is now an abstract class, but all the other things under it (Digest::CRC32) are modules? that doesn't seem right...
<straight-shoota>
I don't think Digest::CRC32 changed in any way since 0.35.1
<straight-shoota>
Digest is now an abstract class, yes. And most digest implementations inherit from that through `OpenSSL::Digest`. But not `Digest::CRC32` which is still just a module.
sz0 has quit [Ping timeout: 272 seconds]
<postmodern>
would prefer the old Digest::Base class, to to have all digests inherit from that, wrapping up the OpenSSL bits in the Base API methods.
<postmodern>
also defining sub-things inside the scope of an abstract class is kind of weird
willamin has quit [Read error: Connection reset by peer]
jetpack_joe has quit [Read error: Connection reset by peer]
willamin has joined #crystal-lang
jetpack_joe has joined #crystal-lang
sz0 has joined #crystal-lang
<straight-shoota>
well, whether the base type is Digest::Base or Digest doesn't really make a difference, though
<straight-shoota>
fact is, the API is much more refined now
<postmodern>
not it's not
<straight-shoota>
what not?
<postmodern>
Digest is supposed to contain digests, by changing the type of Digest, it forces everyone to either explicitly write out `abstract class Digest; class Foo < Digest` or `class Digest::Foo < Digest`.
<straight-shoota>
I don't understand the issue with that
avane has quit [Ping timeout: 260 seconds]
<straight-shoota>
if you have a custom digest implementation, it extended from `Digest::Base` and now it needs to be changed to extend `Digest`
willamin has quit [Read error: Connection reset by peer]
<postmodern>
moving things around 1) doesn't make an API less or more refined 2) can break API compatibility
jetpack_joe has quit [Write error: Connection reset by peer]
<oddp>
yeah, hence it was marked as a breaking change in the changelog.
sz0 has quit [Ping timeout: 260 seconds]
<straight-shoota>
ok, renaming from `Digest::Base` to `Digest` would have been avoidable, yes
<postmodern>
also now that CRC32 was moved into Digest::, it conflicts with digest-crc.cr's Digest::CRC32, which inherits from Digest/Digest::Base. grumble
<FromGitter>
<HertzDevil> what's the difference between `type_merge` and `type_merge_union_of`?
<FromGitter>
<RespiteSage> @asterite Thanks for the quick fix on that weird `#is_a?` issue!
jetpack_joe has joined #crystal-lang
<straight-shoota>
Digest::CRC32 has been moved since 0.34 so that's far from a new change.
<straight-shoota>
if digest-crc hooks into stdlib namespaces, that can cause conflicts
willamin has joined #crystal-lang
sz0 has joined #crystal-lang
<postmodern>
grumble, was hoping Digest would remain an open namespace for people to define additional digest algorithms
<straight-shoota>
I guess you can do that. But when a new algorithm is added to stdlib, it's going to take that name
<postmodern>
i guess i should define my own namespace
<straight-shoota>
yeah, that's what shards ideally should do.
<straight-shoota>
but adding custom digest algos into `Digest` namespace doesn't sound like a bad idea in general
avane has joined #crystal-lang
willamin has quit [Ping timeout: 265 seconds]
jetpack_joe has quit [Ping timeout: 272 seconds]
sz0 has quit [Read error: Connection reset by peer]
yxhuvud has quit [Ping timeout: 260 seconds]
yxhuvud has joined #crystal-lang
willamin has joined #crystal-lang
jetpack_joe has joined #crystal-lang
sz0 has joined #crystal-lang
<FromGitter>
<mavu> Hi ⏎ I'm trying to make an importer that puts data from a csv into a postgres db. ⏎ I have something that works, but I wanted to try to make use of -Dpreview_mt and I have problems getting the setup right. ⏎ Is there somewhere a example of how to structure your spawns and channels? ⏎ I tried spawning workers that do a channel.receive and insert into Postgres. ... [h
<FromGitter>
<dansimpson> Hey folks, testing out 0.36 (thanks!) and I am now getting an error for something which was a warning before. I have a method which returns a new instance of the class, with different type parameters. It works like map, on a result type ... similar to rust: `def and_then(&block : V -> Result(U, E)) : Result(U, E) forall U` ... but now i get `Error: can't resolve return type Result(U, E)`
<FromGitter>
<oprypin:matrix.org> @dansimpson: i see `forall U` but where's `V`, `E`
<FromGitter>
<dansimpson> `abstract class Result(V, E)`
<FromGitter>
<dansimpson> I'm trying to map to a Result(U, E) using a block which is expected to return an instance of Result(U, E)
<FromGitter>
<dansimpson> it worked in 0.35.1 with a warning, so I get that it's now an error, but I just don't really know how to make the compiler happy here. I could try removing return type annotations, but I generally like being explicit.
<FromGitter>
<oprypin:matrix.org> @dansimpson: is this code published anywhere?
<FromGitter>
<dansimpson> One second, I'll create a gist
<oddp>
As a crystal newbie, what's the benefit of having a result type over `String?`?
<straight-shoota>
oddp, you mean a value type wrapping String?
<oddp>
alias StringResult = Result(String, Exception) as in the gist
<straight-shoota>
ah okay
<straight-shoota>
not sure what that does.
<straight-shoota>
It's not idiomatic in Crystal. Looks more like something you would to in Rust maybe
<FromGitter>
<Blacksmoke16> @dansimpson fwiw the interface defines `and_then(&block : V -> Result(V, E)) : Result(V, E)` but the implementation is `and_then(&block : V -> Result(U, E)) : Result(U, E) forall U`
<FromGitter>
<Blacksmoke16> notice `Result(U, E)` instead of `Result(V, E)`
<FromGitter>
<Blacksmoke16> making it ` def and_then(&block : V -> Result(V, E)) : Result(V, E)` compiles
ua has quit [Ping timeout: 264 seconds]
ua has joined #crystal-lang
ua has joined #crystal-lang
_ht has quit [Remote host closed the connection]
<FromGitter>
<dansimpson> @Blacksmoke16 hmm, let me check on that
richbridger has quit [Remote host closed the connection]
<FromGitter>
<dansimpson> Yeah, that compiles, but it no longer allows mapping to a different type. The pattern is for chaining .and_then to create sequences that depend on the prior stage, without having a bunch of if statements.
<FromGitter>
<Blacksmoke16> so then maybe update the interface def to match that of your implementation?
<FromGitter>
<dansimpson> Yeah, changing the abstract signature just moves the compiler error to that line.
<FromGitter>
<Blacksmoke16> welp
<FromGitter>
<dansimpson> At one point it wasn't a warning, then a warning, and now an error. Maybe this pattern is no longer possible... I do really enjoy the pattern!
<FromGitter>
<Blacksmoke16> not a common thing in crystal tho fwiw
<FromGitter>
<Blacksmoke16> could try just not adding types, or be less strict
<FromGitter>
<dansimpson> I'll give that a god
<FromGitter>
<asterite> @HertzDevil I think `type_merge` will unify types in a type hierarchy, but `type_merge_union_of` won't. So with `A`, `B < A` and `C < A`, type_merge of B and C would give A, while the other one would give `B | C`
<FromGitter>
<Blacksmoke16> id be curious to see an example of how you use that `and_then` and stuff
<FromGitter>
<asterite> @dansimpson very easy: don't use an abstract def. You'll get a compiler error anyway if you use it wrong (in my opinion abstract defs are a feature I'd like to remove)
<FromGitter>
<Blacksmoke16> i mainly like them for the docs
<FromGitter>
<dansimpson> @asterite what do you recommend instead of abstract methods? I'm using it to ensure that deriving classes implement it.
<oddp>
"how you use that `and_then` and stuff" -- like `.try` I imagine, that's why I asked about the net positives vs. crystal's checked nils.
<FromGitter>
<Blacksmoke16> seems to be a way to handle exceptions without raise
<FromGitter>
<Blacksmoke16> but :shrug: i was going to try and convert his example into more idiomatic crystal to compare ;p
<FromGitter>
<Blacksmoke16> @dansimpson he means just dont use them at all, as the compiler will still error if a child type doesnt implement one of the methods
<FromGitter>
<dansimpson> This is good stuff, and I am open to it
<FromGitter>
<Blacksmoke16> er `path = unpack(tgz)`
<FromGitter>
<dansimpson> yeah, that style could work too
<FromGitter>
<Blacksmoke16> anything that fails would bubble up thru each rescue block
<FromGitter>
<Blacksmoke16> this idea of using like `Result | Error` unions and stuff comes up every now and then. I see the benefit, but most of the time imo its better to just use exceptions
<FromGitter>
<Blacksmoke16> then your code most likely fits into rest of crystal ecosystem and such
<FromGitter>
<Blacksmoke16> versus "ogh, this lib uses some strange rust/go style thing and its a pain to integrate it"
<oddp>
Why exceptions? Checked nil does fit Maybe types, doesn't it?
<oddp>
We have .try, .not_nil! and || default.
<FromGitter>
<Blacksmoke16> depends on exact context, `nil` is a good pseudo error handling thing but sometimes something happens you cant recover from, i.e. its exceptional
<FromGitter>
<dansimpson> Maybe seems to be more core, but Either/Try is a bit different.
<FromGitter>
<Blacksmoke16> i.e. if that `Dir.mkdir_p(releases_dir)` fails, you cant do anything else
<FromGitter>
<Blacksmoke16> ah ok, got an example of those?
fifr[m] has quit [Ping timeout: 265 seconds]
<FromGitter>
<mattrberry> Does anybody with Mac, Crystal 0.36.0, and OpenGL experience want to help debug why I can't get the shaders to work on my emulator? They work fine on Linux, but I don't have a Mac to debug on
<oprypin>
mattrberry, how do u know that shaders dont work
<FromGitter>
<mattrberry> I have a friend with Mac who says they're not compiling. He doesn't have the technical knowledge to try to fix them. The turnaround of me asking him to change a line or two and try again isn't helping me debug this issue :p
<FromGitter>
<mattrberry> I think it's something related to Mac staying in Legacy Mode rather than going into Core Mode, but I'm not sure why
<FromGitter>
<oprypin:matrix.org> @mattrberry: so last time we pointed out that u were using something from opengl 4.4 which is not available
<FromGitter>
<oprypin:matrix.org> re "they're not compiling" - is this something that is seen on the command line?
<FromGitter>
<mattrberry> Yeah I just put the OpenGL 4.2 debugging stuff behind a `{% unless flag?(:darwin) %}`, so that's not a concern anymore. When we looked at it before, it was also failing to compile the shaders, It's still failing to do that today
<FromGitter>
<oprypin:matrix.org> have you considered using github actions to debug this 😳
<FromGitter>
<mattrberry> Yeah you mentioned that the other day too. I haven't looked into that further since you mentioned it. I was also just debating paying some mac hosting service to rent some time on a mac.. But I figured the easiest approach would be to get help from someone knowledgeable :p
<FromGitter>
<Blacksmoke16> gh actions has mac and windows
<FromGitter>
<mattrberry> The people in the emudev community are super helpful, but there's nobody there who uses Mac *and* knows Crystal haha
<oprypin>
mattrberry, lemme try to give you a gh actions setup first
<FromGitter>
<oprypin:matrix.org> @mattrberry: why do zips if you can just push to github ಠ_ಠ
<FromGitter>
<mattrberry> I didn't want to push broken code to github haha
<FromGitter>
<mattrberry> I just don't have a good way to test it locally..
<FromGitter>
<oprypin:matrix.org> well i need this fix
<FromGitter>
<mattrberry> I'll make a more minimal test case
<FromGitter>
<mattrberry> You'd need to make modifications anyway to have that code run without a bios/rom
<FromGitter>
<oprypin:matrix.org> @mattrberry: no that's fine, i only want to work on a github actions setup and just need code that builds on crystal
<FromGitter>
<oprypin:matrix.org> ok it's easy enough
<FromGitter>
<mattrberry> The zip I sent is all you'd need for that. The only changes to make it compile on 0.36.0 are to remove the `: Bool` on the abstract `===` method in abstract_channels.cr, and to change the `delete_if` call to `reject!` in scheduler.cr
<FromGitter>
<mattrberry> There are other runtime changes in 0.36.0 now that throw exceptions when they didn't before that would cause the emulator to crash, but that won't matter unless you care about actually running it
<FromGitter>
<oprypin:matrix.org> @mattrberry: fyi if u want to support Windows it's probably very much doable. though the opengl shard you're relying on didnt include windows support (would be trivial to add)