<frojnd>
I have a string which represents date "2021-08-01"
<frojnd>
I would like to validate it. If format is correct. I see there is parse https://crystal-lang.org/api/1.2.0/Time/Format.html#parse%28string%2Clocation%3D%40location%29%3ATime-instance-method but not sure how can I use it
<FromGitter>
<syeopite:matrix.org> But if you want to just use`Time::Format`, you'll have to initialize it first. ⏎ ⏎ ```Time::Format.new("%Y-%m-%d", location: Time::Location::UTC).parse("2021-08-01")``` [https://gitter.im/crystal-lang/crystal?at=61696bf129ddcd029323c299]
<frojnd>
Thank you!
<FromGitter>
<Blacksmoke16> ofc would have to rescue the exception. Technically this is more so trying to parse it and handling the error state versus just validating it
<frojnd>
Yeah
<FromGitter>
<Blacksmoke16> if you just want to check it's format could do like `str.matches? /^(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})$/`
<frojnd>
I have problem actually ... parse("2021-08-1") doesn't throw an exception, even though I expect this string to no be validated because of the `%Y-%m-%d`
<frojnd>
That's what I need
<frojnd>
matching patterns! But will also use error state handling.
<FromGitter>
<Blacksmoke16> is it actually a problem `1` works versus `01`?
<FromGitter>
<Blacksmoke16> i did confirm it raises on if it's actually invalid, i.e. `2021-13-01`
<frojnd>
Yeah your matching actually works for my use case
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<y8> @jwaldrip:matrix.org in progress :) formula fails to build on 10.14, @maxfierke is guiding me through it
<FromGitter>
<syeopite:matrix.org> That's a stdlib bug isn't it? %d is supposed to match a zero padded day
<FromGitter>
<Blacksmoke16> im pretty sure the struct isn't bound correctly, but seems to work with other flags? 🤔
<FromGitter>
<Blacksmoke16> oh i need to set the `unsigned char **mark` this would be like `mark : LibC::UChar**` yea? ⏎ ⏎ Then I'm doing ⏎ ⏎ ``` @mark = Pointer(UInt8).malloc 3 ⏎ @extra.value.mark = pointerof(@mark)``` ... [https://gitter.im/crystal-lang/crystal?at=61697e9638377967f453463b]
<FromGitter>
<Blacksmoke16> SOLVED: their `(not necessarily in this order)` was correct, updated to match what the typedef was and no error now
<FromGitter>
<jwaldrip:matrix.org> Anyone here have rights to the asdf repo for crystal?
<FromGitter>
<jwaldrip:matrix.org> would love to get this merged today
<FromGitter>
<jemc> Anybody know if the Crystal compiler has a way for me to link some external LLVM bitcode that I provide at invocation so that my Crystal program can benefit from LLVM optimizations across the boundary of a C library? ⏎ ⏎ Basically I'm looking for a way to provide a `.bc` file at invocation and have Crystal call `LLVMParseBitcodeInContext` to parse the bitcode and `LLVMLinkModules2` to link it to the LLVM IR
<FromGitter>
... for the Crystal program. ⏎ ⏎ I can alternatively accomplish this by having Crystal emit the `.bc` for the program and then invoke `llvm-link` and then `llc` externally. But it would be cleaner if there exists a way to get the Crystal compiler to do it in one invocation. [https://gitter.im/crystal-lang/crystal?at=6169a1aa3f09d8573615c47d]
<yxhuvud>
jemc: Dunno if you can link against a .bc, but you can definitely link against .o or .a files.
<FromGitter>
<jemc> Yeah, I'm already linking against a `.a` right now, but I'd get better LLVM optimizations if I could link as `.bc` prior to the LLVM optimization step (which for example, would allow calls to trivial C functions to be inlined into the Crystal code)
<yxhuvud>
ok. Well then I don't know, but would be interested to see if you solve it
<yxhuvud>
I wonder if you'd need thinLTO enabled in practice for that to work though, and currently that isn't supported
<FromGitter>
<jemc> I think ThinLTO is an alternative way of accomplishing the same general goal
<yxhuvud>
ok. I mentioned it as I knew that also make use of llvm bitcode in the process of linking and probably need some of the same machinery
<FromGitter>
<jemc> The approach I described above (`LLVMParseBitcodeInContext` and `LLVMLinkModules2`) is what I'm using already in the Savi compiler to link the program to the Pony runtime. ⏎ ⏎ The Savi compiler is written in Crystal and uses the same LLVM bindings, but looking back at my code now I see that those two LLVM functions I had to bind myself by extending Crystal's `LibLLVM`, so it seems unlikely that this is
<FromGitter>
... possible in the Crystal compiler today if those functions aren't bound
<FromGitter>
<jemc> If there are other people interested in using this feature in the Crystal compiler I could potentially do a PR to add it, perhaps as an alternative link annotation
<FromGitter>
<jemc> A shard that has some C functions in it could potentially distribute the `.bc` (compiled for various common triples) as part of the shard, and if there was a link annotation supported natively in Crystal, then those C functions could be accessible (and inlined) with no extra steps for the end user of the shard
yxhuvud has quit [Remote host closed the connection]
yxhuvud has joined #crystal-lang
hightower2 has joined #crystal-lang
Munto has quit [Ping timeout: 252 seconds]
Munto has joined #crystal-lang
<FromGitter>
<y8> It’s rare when you can appreciate that M1 is insanely fast. Crystal compiles crystal in 5 minutes on my MacBook Air that have exactly zero fans. Only thing I’ve noticed after compiling crystal for a while, is that I had to go and plug latptop in charger few hours earlier than usual. 🤯
<FromGitter>
<Blacksmoke16> 5min?! non-release i assume?