<FromGitter>
<wyhaines> Sooooo.... I was reading the 0.35.0 changelog. Does this mean that 0.35.0 can be built and used directly on Windows (vs via WSL?)
rocx has joined #crystal-lang
deavmi has joined #crystal-lang
<FromGitter>
<watzon> Challenge for someone. What would be the most efficient way to convert `Bytes` into a `Pointer(Uint64)`? ⏎ Apparently `String` is capable of that all by itself, but `Slice` isn't.
<FromGitter>
<Blacksmoke16> er, wouldnt be `UInt64` tho
<FromGitter>
<watzon> Yeah that's the problem
<FromGitter>
<watzon> Is there no way to copy the memory from one pointer to another when the pointers are a different size?
<FromGitter>
<Blacksmoke16> what about like `Pointer(UInt64).new(slice.to_unsafe.address)` :S
<FromGitter>
<Blacksmoke16> i feel like thats a terrible idea tho
<FromGitter>
<watzon> It's kinda terrible, but if it works... Lol
<FromGitter>
<watzon> Which it does
<FromGitter>
<Blacksmoke16> im not familiar enough to know if thats going to cause problems because of the change in `T`, also ⏎ ⏎ > This doesn't allocate memory.
<FromGitter>
<watzon> Damn, creating `Bytes` directly using `Bytes[45, 56, 75, 44]` is so much slower than creating a String
<FromGitter>
<Blacksmoke16> so not sure if that would get GC'd over stack overwritten or something
<FromGitter>
<Blacksmoke16> or stack*
<FromGitter>
<watzon> Hmm
<FromGitter>
<watzon> I guess we'll find out at some point
<FromGitter>
<watzon> Yeah it looks like that's definitely not a good option
<FromGitter>
<Blacksmoke16> you dont say :P
postmodern has joined #crystal-lang
<postmodern>
what is the crystal way of allocating a literal Bytes object? `"str".bytes`?
<postmodern>
er "str".to_slice
<FromGitter>
<Blacksmoke16> both are the same thing afaik
<FromGitter>
<Blacksmoke16> nvm, `bytes` returns an array, if you want a slice you would want to use `to_slice`
<FromGitter>
<watzon> Anyone know how to create a C struct from a number? For instance I have a struct with 2 UInt32 fields and a UInt64 that I want to pack into that struct.
<FromGitter>
<watzon> `num.unsafe_as(TheStruct)` doesn't seem to be doing it
<oprypin>
@watzon: i surely know but i don't know what you're requesting
<FromGitter>
<watzon> Because the `mem::transmute` documentation says "Both types must have the same size. Neither the original, nor the result, may be an invalid value.", but `RBasic` should be twice the size of `InternalValue`
<FromGitter>
<watzon> Since it contains two of them
<raz>
blacksmoke16: better!
<raz>
speaking of better...
<raz>
watzon: event_emitter.cr is really cool, why do you guys leave the release version in a broken state?
<FromGitter>
<watzon> That's @hugoabonizio's project I believe. I didn't realize it never got a release after we overhauled things.
<raz>
yup no biggie, master works fine, just had me confused for a moment
<FromGitter>
<watzon> Something makes me think that `mem::transmute` is doing something different than a pointer cast oprypin. The rust docs say it "Reinterprets the bits of a value of one type as another type" which makes it sound like a pointer cast would work, but idk...
<FromGitter>
<watzon> I'm definitely not getting the right values
<FromGitter>
<watzon> But I'm getting undefined behavior
<FromGitter>
<watzon> The thing is, `Value` is a `LibC::ULong` and `RBasic` is a struct like this: ⏎ ⏎ ```struct RBasic ⏎ flags : Value ⏎ klass : Value ⏎ end``` ⏎ ⏎ so the struct that I'm casting `@value` to is twice the size of `@value` [https://gitter.im/crystal-lang/crystal?at=5ee083b0ef5c1c28f013ce4b]
<FromGitter>
<watzon> So I keep ending up with stuff like this `LibRuby::RBasic(@flags=26382920, @klass=26382920)`
<FromGitter>
<watzon> Where flags and klass contain the same value
<FromGitter>
<naqvis> guess, you would need to cast that to pointer
<FromGitter>
<watzon> Cast what to a pointer?
<FromGitter>
<naqvis> `Value`
<FromGitter>
<watzon> > Well this code should be about the same, if `mem::transmute` had the same behavior ⏎ > ```crystal ⏎ > def builtin_type ⏎ > basic = pointerof(@value).as(LibRuby::RBasic*).value ⏎ > masked = basic.flags & LibRuby::ValueType::Mask.to_u64 ... [https://gitter.im/crystal-lang/crystal?at=5ee086075dcbb760b6de479d]
<FromGitter>
<naqvis> gotcha, then what is issue now you are experiencing?
<FromGitter>
<naqvis> getting wrong value?
<FromGitter>
<watzon> Yeah for some reason I'm ending up with duplicated values. Apparently rust's `mem::transmute` is like a C `memcpy` operation, I don't think the pointer cast is doing the same thing.
<FromGitter>
<naqvis> have you tried using `unsafe_as`?
<FromGitter>
<watzon> Yeah tried that as well
<FromGitter>
<naqvis> so you mean `basic = pointerof(@value).as(LibRuby::RBasic*).value` is pointing to invalid obj?
<FromGitter>
<watzon> That's what it seems like, I keep ending up with values like `LibRuby::RBasic(@flags=36213320, @klass=36213320)`
<FromGitter>
<watzon> The `flags` and `klass` values definitely shouldn't be the same thing
MasterdonX has quit [Ping timeout: 265 seconds]
<FromGitter>
<naqvis> agree
MasterdonX has joined #crystal-lang
<FromGitter>
<naqvis> do you have sth small, with which i can fiddle with?
<FromGitter>
<watzon> I'll see if I can come up with something in the morning if you're still around
<FromGitter>
<watzon> For now I need to rest my brain and sleep haha
<FromGitter>
<naqvis> did you check the function body execution path?
<FromGitter>
<naqvis> might be some path returning Nil
<FromGitter>
<naqvis> aah, its part of stdlib :P
<FromGitter>
<bararchy> oprypin, this seems to happen on `Time.utc.to_rfc3339` can't believe this wasn't tested in specs
postmodern has quit [Read error: Connection reset by peer]
postmodern has joined #crystal-lang
sz0 has quit [Ping timeout: 256 seconds]
sz0 has joined #crystal-lang
zorp_ has joined #crystal-lang
<FromGitter>
<waghanza> Hi, ⏎ `brew` (`linux` and `osx`) still use *0.34*. Is there a plan to update formulas to *0.35* (I have not enough skill to do it myself) ?
<FromGitter>
<bararchy> So IO.write was changed to : `abstract def write(slice : Bytes) : Int64`
<FromGitter>
<bararchy> so it now "has" to return Int64
<FromGitter>
<naqvis> @waghanza I just checked the history of linuxbrew and seems that's isn't maintained by core team
<FromGitter>
<naqvis> so for linuxbrew either you can wait for PR from someone else, or you can proceed with raising the PR
<FromGitter>
<waghanza> @naqvis I'll put in my todo, but could take time, I've to learn `brew` before ⏎ just notice that `brew` installation is proposed in https://crystal-lang.org/install/on_fedora/
skrzyp has joined #crystal-lang
<FromGitter>
<naqvis> sure, but on linux snap works good. Also snap is updated quite quickly for latest crystal versions
<FromGitter>
<waghanza> of course, but propably having `brew` listed for `linux` is then not accurate
skrzyp has quit [Remote host closed the connection]
<FromGitter>
<manveru> seems like `make docs` is broken in 0.35?
<FromGitter>
<hugoabonizio> @raz @watzon sorry, I've been away from crystal community lately doing my master's but I just released a new version with @watzon's overhaul, should be fine now
<raz>
i guess spawn is very cheap, but shouldn't it rather only spawn when something actually matches 🤔
skrzyp has quit [Quit: WeeChat 2.7.1]
<raz>
(i.e. when many listeners are registered then the current version might do dozens of spawns on each `emit`)
<FromGitter>
<j8r> @oprypin The next version may be 1.0.0, I only hope it won't be rushed – and this takes more time
<oprypin>
@bararchy: i assumed that you isolated the issue before proclaiming it as a problem in stdlib. you gotta make sure to post a full example that shows the issue. that saves time of multiple people
<FromGitter>
<Blacksmoke16> it was happening for crushtache (idk how to spell it) but it has since been fixed
<FromGitter>
<bcardiff> @manveru `make docs` requires you to have done `make crystal` first. Sometimes is because the language change from one version to another and sometimes because new cli options are added (this case).
OvermindDL1_ has joined #crystal-lang
OvermindDL1 has quit [*.net *.split]
dannyAAM has quit [*.net *.split]
OvermindDL1_ is now known as OvermindDL1
<FromGitter>
<jeff-hykin> For dependency management of a particular shard, would it be difficult to contribute a feature where the parser highlights all cases of system calls (e.g. system("echo hello")), reading in files, and uses of environment variables ? Basically for performing a kind of portability check on a library.
<FromGitter>
<Blacksmoke16> most of those should already be abstracted by crystal itself id imagine
<FromGitter>
<jeff-hykin> I'm not quite sure what you mean. Would the abstraction make it easy to find those lines of code?
<FromGitter>
<jeff-hykin> I see there are tools for all of those, and injection into those classes/methods could show runtime calls of system, files, and env vars. I was wonder if there was a parsing system that could point out uses of those features without needing all possible branches to be executed.
<FromGitter>
<Blacksmoke16> no, nothing like that exists at this moment. That would more likely fall to the shards documenting that it requires python if you're using feature x
<FromGitter>
<jeff-hykin> For example say shard1 has a dependency on shard2, and shard2 makes a system call to python2 only under certain conditions. I want to ensure the code runs for all conditions so I want to see that hidden conditional dependency before the program crashes.
<FromGitter>
<jeff-hykin> If it's a difficult feature for the parser to find all those cases that's okay. I was just curious if it was easy to create some kind of filter that scans the AST for particular tokens. If it's much more difficult than that, it's probably not worthwhile for me to attempt to contribute it.
<FromGitter>
<Blacksmoke16> could maybe make a forum post about it
<jhass>
the compiler and thus parser is shipped in the stdlib, it doesn't have to be compiler feature. ameba is a good example of how to build such tools ontop of that
<FromGitter>
<watzon> I would if it was my library haha
<FromGitter>
<Blacksmoke16> :S
<FromGitter>
<Blacksmoke16> *doomed*
<FromGitter>
<watzon> Luckily it looks like that was the only place they did that, I can PR the fix pretty easily
<FromGitter>
<Blacksmoke16> sounds like a plan
<FromGitter>
<j8r> @watzon yes the parsing was changed
<FromGitter>
<j8r> you can use the standard type annotation
<FromGitter>
<j8r> Also, I think you want to use Nil, not Void
<FromGitter>
<j8r> omg that's confusing, I thought it was a Hash
<FromGitter>
<j8r> `[] of DB::Database -> Void` vs `{} of DB::Database => Void`
<FromGitter>
<watzon> Yeah lol, so did I at first
<FromGitter>
<j8r> I never liked the `of` syntax :(
<FromGitter>
<j8r> anyway, a good fix is `Array(Proc(DB::Database, Nil)).new`, or like the type annotation, `Array(DB::Database -> Void).new`
<FromGitter>
<Blacksmoke16> `of` has its uses
<FromGitter>
<Blacksmoke16> for cases where you cant that ^
<FromGitter>
<j8r> I always found weird to have things like `@ary : Array(String) = [] of String`, so much more logical to do `@ary : Array(String) = Array(String).new`
<FromGitter>
<Blacksmoke16> im the opposite in that regard ha, when doing default assignment i like the former since it looks more like a value
<FromGitter>
<Blacksmoke16> :shrug:
<FromGitter>
<j8r> More like a value?
<jhass>
why would you ever do @foo : Type = Type.new, that's just redundant
ht_ has joined #crystal-lang
* FromGitter
* Blacksmoke16 hides
<FromGitter>
<j8r> for example with getter, for API docs
_ht has quit [Ping timeout: 265 seconds]
ht_ is now known as _ht
<FromGitter>
<j8r> or "pin" the type to avoid unwanted unions, with Nil for example. Another place is method arguments
<FromGitter>
<j8r> Anyway, I like using the standard generic syntax - it remind we that Hash or Array are just standard generics, nothing special :)
<FromGitter>
<Blacksmoke16> matter of preference, either is fine
<FromGitter>
<j8r> maybe, except when it doesn't, with `of` parsing issues 😉
<jhass>
could also be interesting to setup a git bisect (run)
<oprypin>
oh yea for sure
<jhass>
that might give you clues on what to reduce to to submit the bug report with a reproducing example
<FromGitter>
<jeff-hykin> Thanks @Blacksmoke16 👍
<FromGitter>
<jeff-hykin> (for the response earlier)
oprypin has quit [Quit: Bye]
oprypin has joined #crystal-lang
oprypin has quit [Client Quit]
oprypin has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 246 seconds]
<FromGitter>
<j8r> I would like to clarify something
<FromGitter>
<j8r> Is Windows support is planned at the end for Crystal 1.0.0, or not?
<FromGitter>
<j8r> Or "only" partially, at the end?
<FromGitter>
<Blacksmoke16> https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html ⏎ ⏎ > Windows: We aim for most of the shards and apps built on Crystal to be portable. The std-lib should hide platform specific aspects as well as possible. With that in mind adding more platforms to the supported list should not impact neither the language nor the public API. Again, recently we integrated a CI for Windows to ensure we
<FromGitter>
<bararchy> To anyone interested, @bcardiff helped me debug this issue, it took us a bit more then an hour, but we zoomed in on the issue and even got a workaround for it, seems we are doing too much crazy stuff in NeuraLegion ahahah fuzzing the crystal compiler
zorp_ has quit [Ping timeout: 264 seconds]
<FromGitter>
<kinxer> Does Manas still have a Github? I'm looking through their Labs section on the website, and the links to projects are broken.
<FromGitter>
<bcardiff> @kinxer what links you noticed are broken?
<FromGitter>
<kinxer> Brium and Code Games.
<FromGitter>
<kinxer> Also, I'm reading on Wikipedia about L-Systems now because of the previous Tree Generation work (which is something I'd considered trying in the past but hadn't gotten around to).
<FromGitter>
<bcardiff> Brium and Code Games are not open source. Neither the tree generator. The landing page of them seems to be working fine, but you will find no public source code.
<FromGitter>
<kinxer> A'ight. There are links to GitHub at the bottoms of those pages.
<FromGitter>
<bcardiff> (Not fun fact: the Brium name comes from Brian :-P)
<FromGitter>
<bcardiff> ooooh. yeah. those should not be there.
<FromGitter>
<kinxer> Also, I knew the tree generation wasn't open-source (since it's in the "Work" section).
<FromGitter>
<kinxer> I'm just excited to learn the basics of how I might do something like that.
<FromGitter>
<Blacksmoke16> so whats the best way to run a scheduled job these days
<FromGitter>
<Blacksmoke16> point cron as a crystal binary?
<FromGitter>
<Blacksmoke16> at a*
<FromGitter>
<Blacksmoke16> airflow would prob be overkill
<FromGitter>
<Blacksmoke16> mosquito has the ability, but dunno if its worth having a dependency on redis just for that
<FromGitter>
<kinxer> Have a long-running crystal binary that calculates the time to the next scheduled run, sleeps for that exact amount of time, runs, and then sleeps again? :P
<FromGitter>
<Blacksmoke16> would be every 30min, so prob not the worst idea
<FromGitter>
<kinxer> Honestly, it probably depends on how you intend to be able to deploy. If you have a specific OS target, you could probably use whatever service tool is used.
<FromGitter>
<kinxer> If it's meant to be cross-platform, I think I'd probably go with cron or the semi-joking suggestion I made above.
<FromGitter>
<Blacksmoke16> i mean that might not be a terrible solution
<FromGitter>
<bararchy> If windows you can put it under services, but you will need the shitty install as service logic, if it's linux, systemd or cron
<FromGitter>
<Blacksmoke16> naw it'll be linux
<FromGitter>
<Blacksmoke16> essentially there is an API i want to consume that is cached for 30min
<FromGitter>
<Blacksmoke16> so every 30min just want to pull for latest data
<FromGitter>
<kinxer> Also, the `sleep 30.minutes` won't stay aligned with the start time, especially if the task is doing a lot of work.
<FromGitter>
<kinxer> But that only really matters if you want cron-like behavior (e.g. performing the task at exactly 0 and 30 minutes each hour).