<repo>
hey, is there a "fail fast" option for spec?
<repo>
the help output doesn't suggest there is one, but i thought i'd ask anyway
<repo>
ok it's just --fail-fast :)
<FromGitter>
<HertzDevil> good news: neither crystal-lang/crystal#6473 nor crystal-lang/crystal#9524 actually needs nested yields to trigger
<repo>
oh wait a second, --fail-fast apparently isn't a thing
<repo>
hm but it is..
<repo>
hm ok it doesn't abort on errors, only on failures
<raz>
i don't understand why fail-fast isn't just the default
<raz>
when would you ever want anything else?
* raz
likes -v --order random --fail-fast
<Andriamanitra>
unless the specs take significant amount of time to complete i don't see a reason to --fail-fast
<Andriamanitra>
would be a bit weird as default
<raz>
specs always take too long to complete
<raz>
and when there is an error, you don't normally want to wait for the message to come up, only for it to then be cluttered by follow up errors
<yxhuvud>
it shouldn't be the default, but I could see a config file where options like that can be specified
<FromGitter>
<erdnaxeli:cervoi.se> the longest part on spec is the compilation, and for that you can run just a specific file
<FromGitter>
<erdnaxeli:cervoi.se> (in my experienc)
Vexatos has joined #crystal-lang
skrzyp has quit [Ping timeout: 256 seconds]
<repo>
heh no
<repo>
specs for the project i needed --fail-fast for take roughly 8 minutes
<Andriamanitra>
out of curiosity how much of that is compilation?
<FromGitter>
<erdnaxeli:cervoi.se> wow, 8 minutes! what kind of project is that?
<yxhuvud>
does it put thousands of records into a db for every spec?
<repo>
Andriamanitra: lemme check
<repo>
it's an media asset management system. It features conversions, resizing, transcoding of images/videos.
<repo>
compile time is 27s
<repo>
(without --release)
<repo>
it features different storage adapters, e.g. s3/minio or local file storage and streams all data. E.g. hashing is done while streaming the request body into s3 or transcoding is done by streaming the file from the storage adapter to ffmpeg and the output directly to the response body.
<repo>
that way the memory footprint is very small so it's easy to just spawn 10 instances and load balance between them
<repo>
but you can imagine that specs take a while especially when converting/transcoding media
<FromGitter>
<erdnaxeli:cervoi.se> I do
<repo>
i guess the memory footprint would be equally small when using tempfiles but it would be a lot slower
<FromGitter>
<HertzDevil> well, running the crystal compiler's semantic tests alone takes way more than 8 minutes
<FromGitter>
<HertzDevil> so i just put `focus: true` on new tests and remove them on pushes and hope that ci doesn't break
gangstacat has quit [Ping timeout: 272 seconds]
gangstacat has joined #crystal-lang
<repo>
yeah
MasterdonX has quit [Ping timeout: 256 seconds]
Volk has joined #crystal-lang
<FromGitter>
<sclee15> Hello. ⏎ Can I ask a question? ⏎ For given an instance of XML::Node, Can I get XPath of the node?
<FromGitter>
<Blacksmoke16> i.e. get an XPath to that specific node from the root?
<FromGitter>
<sclee15> @Blacksmoke16 Yes. that is what I want.
<FromGitter>
<Blacksmoke16> idt thats a thing
<FromGitter>
<Blacksmoke16> might be something in libxml that could be added tho
<FromGitter>
<sclee15> Okay, I just wanted to check there is no standard way of doing it in crystal. ⏎ Maybe I should write one.
<FromGitter>
<sclee15> Thannk you @Blacksmoke16
<FromGitter>
<Blacksmoke16> the xml implementation in crystal is based on http://www.xmlsoft.org/. So if there is some function in there to do it, it would be fairly straightforward to implement
<FromGitter>
<sclee15> Cool. Thank you again!
flaviodesousa has joined #crystal-lang
<FromGitter>
<jwaldrip:matrix.org> Do we have any idea on what the next version of Crystal looks like?
<FromGitter>
<Blacksmoke16> looks like?
<FromGitter>
<jwaldrip:matrix.org> What is the timing on the next version? Are we nearing 1.0, will we have mac m1 support, and anything else of considerable mention?
<FromGitter>
<Blacksmoke16> the next release will be a pre release of 1.0
<FromGitter>
<Blacksmoke16> :shrug: on timing, but there's an issue for m1 support
<FromGitter>
<Blacksmoke16> going to be a big release at this point
* FromGitter
* Blacksmoke16 would rather have 0.36.0 now
<FromGitter>
<erdnaxeli:cervoi.se> yeah…
<FromGitter>
<jwaldrip:matrix.org> An issue solving m1 support? or an issue outstanding even after the prerelease comes out?